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I'm so honored that ABPMP asked me to write the foreword to the third version of 
the ABPMP Common Body of Knowledge. Why? Because the certification work that 
ABPMP has embarked on is one of the most important initiatives in the business 
process management (BPM) sphere. At Forrester Research, we know there are not 
nearly enough trained process professionals to meet the growing demand for skilled 
BPM-knowledgeable and experienced employees, and the lack of skilled 
practitioners will hold back the adoption of BPM for process improvement and 
transformation. 

While North American and European economies continue to experience unrelenting 
job cutbacks, chronic unemployment and underemployment, and stagnant salaries, 
the BPM skills shortage is a great news (not just a good news) story for people 
looking for work or wanting to advance their careers, whether in business or IT. But 
the issue goes beyond individuals getting trained in BPM for their own 
advancement: companies not only seek to fill positions now but also will scale their 
training programs over the next decade to staff an accelerating BPM transformation 
program. This means that businesses and government agencies must step up to the 
internal challenge of adequately training a large number of knowledgeable BPM 
practitioners, and also that more professional organizations must provide a place 
and way for people to craft and hone their skills. 

But that’s not all. Recently, Forrester identified the need for organizations to move 
their BPM focus to Big Process to support process-driven businesses of the future. 
We defined Big Process as follows: 


When senior-most business and technology leaders embrace 
business process change by shifting the organization’s focus 
from isolated BPM and process improvement projects to a 
sustainable, enterprise-wide business process transformation 
program supported by top executives. 


Further, we said there are Five Tenets of Big Process thinking: 

Tenet 1: Transform Processes, Don’t Just Improve 

Tenet 2: Give The Customer Control 

Tenet 3: Globalize, Standardize, And Humanize Processes 

Tenet 4: Embrace Big Data 

Tenet 5: Double Down On Process Skills 

These tenets mean that organizations will double down on hiring, building and 
growing BPM skills, and also that experienced BPM practitioners will expand their 
knowledge to include new disciplines, such as how customer experience and big 
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data fit into business processes. That’s where ABPMP and the Common Body of 
Knowledge come in. They fill a vital role. 

It’s so ironic that — having decided to work on this foreword today — when I opened 
my e-mail inbox this morning, the very first message I received (from the UK) said: 

"Read your article on BPM and am interested in developing BPM skill-sets. How best 
can I go about acquiring the necessary skill set?" 

And my response was: 

"1 recommend that you check out the certification program from ABPMP, the 
Association of Business Process Professionals. They have a Common Body of 
Knowledge that you can download from their website or buy in book form, and then 
take the certification test. I think that is a very good first step." 

What a great validation that people all over the world really need and even crave the 
material in this BPM Common Body of Knowledge. 

Here’s how I personally know that BPM skills are in high demand: 

Process islands within organizations. In my work with large companies and 
government agencies, I run into many groups within organizations that have deep 
process skills, often with expertise in Lean, Six Sigma, Lean Six Sigma or other 
methodologies and tools. Typically these folks are within business operations or 
spread across business units, or less often, they may be within IT. It’s amazing how 
often these impressive specialists in process excellence or process improvement 
don’t know much about BPM suites or the discipline of BPM. In my view, applying all 
this process intellect and firepower to improve or transform a process without 
codifying it in software is a mistake. That’s because it’s hard to sustain process 
changes without embedding them in the software that people use to get work done. 
Process practitioners need to understand the other side of the BPM coin — the 
technologies that support processes. 

BPM technology pockets within organizations. Similarly, a few BPM software 
specialists can be found in isolated islands of the organization, usually in IT. These 
specialists (and there are not many of them) understand how BPM software works 
and see it as part of the new application-development platform for next-generation 
applications, which embody a process. Often these specialists have deep 
backgrounds in programming: they understand business rules technologies, event 
management, analytics, social media, and mobile technologies, so they embrace 
learning about BPM suites as another new technology to be mastered. And while 
these application developers and enterprise architects may know and understand 
Lean from an Agile perspective, they lack many of the core BPM methodology 
disciplines. They need exposure to the side of the coin that Lean and Six Sigma 
experts already understand. 

Confusion about BPM analyst skills development. Four generic positions are 
essential to a BPM program: 1) the BPM change agent executive who sells the vision, 
drives the program and obtains sponsorship; 2) the business architect or guru with 
a big picture view of process transformation; 3) the process architect who 
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understands the interrelationship between many processes and helps build new 
processes; and 4) the process analyst (or business analyst) who helps with the as-is, 
the to-be, and develops a single process at a time. Many people believe that business 
analysts who already identify requirements — say for ERP or CRM — can move into 
the BPM process analyst job fairly seamlessly. But I've learned through feedback at 
conferences and discussions with senior BPM leaders that most business analysts 
cannot simply move into that position: some don’t have the technical aptitude, while 
others don’t have any interest. But some do have both and want to learn about BPM 
process design. Because there’s a chronic shortage of skilled people, we’ve got to 
find a way to develop their skills so they can move into BPM projects and climb up 
the career-progression ladder over time. 

It’s an exciting time to be in this field. Many new jobs, at a senior level, are being 
carved out even now. That will only accelerate as Big Process takes hold and 
organizations become process-driven enterprises. Training people for these 
positions is a tremendous need, a huge opportunity, and is great for the economy, so 
I am thrilled to see ABPMP step up to the challenge. 



ABPMP President's Note 


BPM is a rapidly growing discipline that is changing the way businesses look at 
managing processes and the role of automation in managing those processes and 
flow of work within and across enterprises. For many of us, this evolving discipline, 
along with the automation that supports it, represents a revolution in delivering 
rapid business change and innovative business capabilities to optimize work and 
the relationships between customers, suppliers, and employees. Through the 
techniques and approaches that it offers, BPM helps to deliver a new level of 
operational management support and a new ability to monitor and measure 
performance at all levels in the company. For those who adopt these approaches, 
techniques, and tools, the playing field is about to change and a new paradigm based 
on rapid, iterative change is about to initiate new ways to look at effectiveness and 
efficiency of business processes 

BPM is now emerging to support enterprise-wide functions and help manage them 
to deliver the promises of continuous improvement. This emerging capability to 
deliver rapid change has promoted a new level of collaboration between business 
and technology professionals who need to understand the strategic nature and 
impact of the changes they are implementing. 

The power of combining BPM methods, approaches, and techniques with the 
supporting BPMS technology is becoming better understood as success stories 
become more and more common across multiple industries. This, in turn, is driving 
a growing awareness of BPM that we believe will continue for many years. 

The third version of the ABPMP CBOK® is a response to a growing demand for 
information on how BPM really works and how it can really help companies 
compete in a global community. As an association, ABPMP has adopted a position 
that there are two very different perspectives on creating a BPM competency. One is 
what we call the foundational concepts, which are based on theory and some form of 
instruction. These are an important component of building competency, but they are 
far from the defining set of capabilities that ensure success. That is why we have 
focused this book and our professional BPM certification on practitioner-level 
knowledge and experience. We believe that the broad and deep practitioner 
experience is at the core of BPM, and that it is essential to ensure consistent success 
in organizations. The result is that this book is not simply theory. It certainly 
provides information on concepts and on the basics, but it also provides advice and 
direction on what needs to be done and how to approach doing it. This makes the 
ABPMP CBOK® unique. 

The experience of the authors and reviewers is also important in a book of this type. 
It represents the collaboration of numerous authors, chapter reviewers, and full 
CBOK reviewers, all of whom are experienced BPM practitioners. Most of these 
people have their Certified Business Process Professional (CBPP®) designation. All 
live in the BPM trenches every day. 

Additionally, the authors are all “doers." They work at all levels, from strategy to 
SOA, but all roll up their sleeves and do the work. That gives a different perspective. 
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This is not simply a compilation of what others have told an author in interviews, 
nor is it based on limited experience. The ABPMP CBOK® is practical and represents 
down-to-earth discussion a wide range of BPM topics. 

As with all emerging disciplines or approaches, terminology and concepts are 
anything but standardized. The variances are evident in ABPMP meetings and in 
discussions at conferences, so the terminology used in this Body of Knowledge will 
certainly follow suit. Recognizing this growing pain in the BPM industry, ABPMP 
provides a glossary with definitions at the end of this book. In addition, we are in the 
process of creating a broader coverage of terminology and definitions in a BPM 
dictionary. Until the industry can mature and standardize, it will be necessary to 
consider terms in each chapter and how they align to the ones you are used to using. 

The result of the approach taken in producing this third version is a "how to" look at 
topics that we hope will introduce new ideas and concepts to those who read it. 

As parts of a common body of knowledge, the chapters are semi-independent of one 
another. Each covers a specific area of BPM. While much can be gained by reading 
the book front to back, cover to cover, it is meant to be much more. The organization 
of the book promotes not only a general reading, but also its use as a reference that 
helps the reader address different aspects of BPM projects. Because it is a 
compendium of knowledge and experience on BPM and business change, it should 
be consulted as needed for focusing on different areas at different phases in a 
project. 

As with any discussion on BPM and business transformation, we expect this 
information to become dated. This book addresses the current and near-future BPM 
world. It represents a solid discussion on what works, by people who must deliver 
its uses every day. But the concepts, techniques, and tools are changing, and ABPMP 
is committed as an association to keeping up with this change. The result is that we 
are planning to send periodic updates of this Common Body of Knowledge to our 
members. Of course updates will only take us so far, and we know that a fourth and 
eventually fifth version will be needed. 

On behalf of the Association of Business Process Professionals, I thank you for 
engaging in this discussion on BPM. Please join us as a member and share your 
experiences at our local chapter meetings or across our membership. I think you 
will enjoy these discussions with your peers. 

Tony Benedict, CBPP 

President, ABPMP International 
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About the CBOK 


Approaching the CBOK® rewrite —Creating Version 3 

The project to rewrite the ABPMP CBOK began in late 2010. The first step was to 
consider the comments that had been collected from people who were using the 
second version of the CBOK®. This was augmented by comments and suggestions 
from association members in Europe and Brazil. In late 2011, the decision was made 
to rewrite the CBOK®. This was because the BPM and BPMS industries had change 
so much that it would be more feasible to start over than to simply add information. 

The project to rewrite the CBOK was headed by Dan Morris. The effort was divided 
into three main sub projects — the chapter rewrite, the chapter content review, full 
CBOK review. In addition, a final professional edit was performed to ensure 
grammar and spelling accuracy. 

The rewrite sub-project was led by Raju Saxena, who made certain we kept the 
rewrite moving. The chapter reviews were led by Owen Crowley, whose dedication 
was unfailing. Dan Morris also led the full chapter review and coordinated the work 
to address comments. Tony Benedict led the final edit and diagram cleanup. 

The approach that evolved recognized that the evolution of the industry has reached 
a point where it will be necessary to create a baseline version and then modify it 
frequently. This modification will address comments and industry changes through 
a release of new sub versions on an as-needed basis. The intent is to highlight 
changes and allow subscribers to download new versions throughout their 
subscription. 

Guiding Principles 

In creating this version, the ABPMP board asked that the following principles be 
used to guide the authors and reviewers. 

• Focus on business practitioners 

• Support a common understanding of BPM 

• Provide a guide to information that aids the alignment of teams and 
organizations 

• Help define a common use of BPM/BPMS language 

• Make certain the discussions are easy to read, thorough, and insightful 

• Reference related disciplines (e.g. Industrial Engineering, Six Sigma, Lean, 
etc.) 

• Contain commonly accepted practices 

• Be vendor- and methodology-neutral 

• Guide (don’t prescribe) 

• Include current concepts 
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Content 


Each chapter in the CBOK® addresses a different topic within BPM and is meant to 
stand alone. The chapters do not follow a chapter-to-chapter discussion using a 
central case that builds from activity to activity. Readers should use the CBOK® as a 
guide that provides comprehensive discussion of topics that, combined, give a broad 
overview of BPM, BPMS, business transformation, and business change. 

The chapters in the CBOK® are: 


Chapter 

Title 

Chapter 1: 

Guide to the CBOK® 

Chapter 2: 

Business Process Management 

Chapter 3: 

Process Modeling 

Chapter 4: 

Process Analysis 

Chapter 5: 

Process Design 

Chapter 6: 

Process Performance Management 

Chapter 7: 

Process Transformation 

Chapter 8: 

Process Organization 

Chapter 9: 

Enterprise Process Management 

Chapter 10: 

BPM Technologies 


The CBOK® version 3 and the ABPMP CBPP® 

Together these topics align with the ABPMP Certified Business Process Professional 
(CBPP™) and support the knowledge testing of the certification test. However, it 
should be noted that while CBOK® provides a firm foundation for practitioners to 
understand the components of BPM, the CBPP™ examination is not based on the 
ABPMP Common Body of Knowledge alone. Experience is the key factor in attaining 
the proficiency needed to pass the CBPP and earn certification. 

Authors 

The authors of this CBOK® were selected based on their expertise, as proven in 
ABPMP chapter meetings, national ABPMP meetings, peer reviews, ABPMP 
committee involvement, publishing, speaking, and industry leadership. All chapter 
authors are ABPMP Certified Business Process Professionals (CBPP). They are, as 
follows: 


Chapter 

Author 

Professional Position 

CBOK® overview 

Connie Moore 

Vice President and Research 
Director, Forrester Research 
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Chapter 1: Guide to the 
CBOK® 

Raju Saxena, 
CBPP 

Senior Manager, Ernst and Young 

Chapter 2: Business Process 
Management 

Denis Lee, CBPP 

President, BizArch Solutions, Inc. 

Chapter 3: Process 
Modeling 

Emmett Powell, 
CBPP 

Enterprise Business Analyst and 
Educator 


Phil Vitkus, 
CBPP 

Business Process Analyst and 
Technical Writer 

Chapter 4: Process Analysis 

Gabrielle Field, 
CBPP 

VP Business Process Improvement, 
Raymond James Financial 

Chapter 5: Process Design 

Dan Morris, 
CBPP 

North America Practice Manager 
for Business Process Excellence, TA 
TA Consultancy Services (TCS) 

Chapter 6: Process 
Performance Management 

Jose Furlan, 
CBPP 

Director of Education Services, 
JDFurlan & Associates Ltd. 


Raju Saxena, 
CBPP 

Senior Manager, Ernst and Young 


Dan Morris, 
CBPP 

North America Practice Manager 
for Business Process Excellence, TA 
TA Consultancy Services (TCS) 

Chapter 7: Process 
Transformation 

Dan Morris, 
CBPP 

North America Practice Manager 
for Business Process Excellence, TA 
TA Consultancy Services (TCS) 


Nancy Bilodeau, 
CBPP 

Sears Holdings Corporation 

Chapter 8: Process 
Organization 

Tony Benedict, 
CBPP 

Vice President Supply Chain, 
Abrazo Healthcare 

Chapter 9: Enterprise 
Process Management 

Dan Morris, 
CBPP 

North America Practice Manager 
for Business Process Excellence, TA 
TA Consultancy Services (TCS) 


Todd Lohr, 
CBPP 

Managing Director, KPMG 

Chapter 10: BPM 
Technologies 

Dan Morris, 
CBPP 

North America Practice Manager 
for Business Process Excellence, 
TA TA Consultancy Services (TCS) 


Marc Scharsig, 
CBPP 

Senior Manager BPM, Accenture 


Michael Fuller 

Independent Consultant 
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All authors contributed on a volunteer basis. The initial consideration in selecting 
authors was to find people with the deep expertise needed to address the topics in 
each of the ten chapters. Once this was done, a rewrite team was formed and each 
chapter’s content was discussed. As the chapters were being written, the authors 
met weekly to discuss concepts, approaches, and techniques to make certain that all 
aligned in the CBOK®. This sharing allowed ideas to be vetted, assured the 
comprehensiveness of coverage, and created a consistent ABPMP perspective. 

Chapter Introductions 

To help provide industry insight, the CBOK® committee was able to engage noted 
BPM experts to share their views on the direction that various topic areas may be 
heading in over the near future. These discussions provide additional value to our 
readers by giving them insight into how these topic areas are expected to evolve. 

The following experts provided discussions in the listed topic areas. 


Chapter 

Industry Expert 

Company 

CBOK® overview 

Connie Moore 

Forrester Research 

Chapter 1: Guide to the CBOK® 



Chapter 2: Business Process 
Management 

Janelle Hill 

Gartner, Inc. 

Chapter 3: Process Modeling 

Craig Le Clair 

Forrester Research 

Chapter 4: Process Analysis 

Elise Olding 

Gartner, Inc. 

Chapter 5: Process Design 

Jim Sinur 

Gartner, Inc. 

Chapter 6: Process Performance 
Management 

David McCoy 

Gartner, Inc. 

Chapter 7: Process Transformation 

David Kish 

TCS Global Consulting 
Practice 

Chapter 8: Process Organization 

Andrew Spanyi 

Spanyi International 
Inc. 

Chapter 9: Enterprise Process 
Management 

Peter Fingar 

Author 

Chapter 10: BPM Technologies 

Dr. Mathias 
Kirchmer 

Accenture 
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Quality and the ABPMP CBOK® 

Quality has been a main concern throughout the CBOK® rewrite process. Our goal 
was to update the coverage in the last version, adding new ideas, changes in the 
marketplace understanding of BPM, and changes in the BPMS technology. To do this, 
ABPMP took an approach that was built on checks and balances. 

To ensure that there were no coverage holes and to uncover any controversial 
discussions, a review committee was formed from additional topic experts. All 
members of the review committee are ABPMP Certified Business Process 
Professionals (CBPP). These reviewers went through each chapter and discussed 
any issues in committee. The discussions resulted in changes that expanded content 
and provided a different, broader perspective on the topic coverage. 

The review committee was managed by Owen Crowley, with content advisory 
provided by Dan Morris and Gabrielle Field. Owen made certain that the reviewers 
remained focused on content quality during the six months of the detailed review. 
The review team members were: 


Review Committee 

Role 

Professional Position 

Owen Crowley, 
CBPP 

Review Committee 
Manager 

President, Exogene Corp. 

Todd Lohr, 
CBPP 

Member 

Managing Director, KPMG 

Marc Scharsig, 
CBPP 

Member 

Senior Manager BPM, Accenture 

Phil Vitkus, 
CBPP 

Member 

Independent Consultant 

Chris Ottesen 

Member 

Specialist Leader, Global Methods 
and Tools, AMEA, Deloitte 
Consulting LLP 

Dan Morris, 
CBPP 

Review Committee Advisor 

NA Practice Manager, Business 
Process Excellence, TA TA 
Consultancy Services (TCS) 


Full CBOK® quality review 

Once modifications were completed, the new CBOK® was reviewed in its entirety by 
the original authors, the review committee, and a third group of new reviewers. The 
goal of this review was to make sure that the new version was understandable and 
complete. 

This approach ensured the accuracy and completeness of content, as well as the 
quality and currency of ideas and discussions. The review delivered a fully vetted 
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and approved discussion of a broad range of BPM and BPMS topics. It also allowed 
the full CBOK® review team to make a final check to ensure that the discussions in 
the CBOK® aligned with the current wisdom, philosophies and approaches 
promoted by the association and accepted by leading industry experts. 

Complete CBOK® version 3 reviewers: 


Reviewer 

Company 

Tony Benedict 

Vice President Supply Chain, Abrazo Healthcare 

Dan Morris 

North American Practice Manager, Business Process 
Excellence, TA TA Consultancy Services (TCS) 

Connie Moore 

Vice President and Research Director, Forrester 
Research 

Janelle Hill 

Vice President and Distinguished Analyst, Gartner, Inc. 

Marc Scharsig 

Senior Manager BPM, Accenture 

Todd Lohr 

Managing Director, KPMG 

Chris Ottesen 

Specialist Leader, Global Methods and Tools, AMEA, 
Deloitte Consulting LLP 

Raju Saxena 

Senior Manager, Ernst and Young 

Denis Lee 

President, BizArch Solutions, Inc. 

Emmett Powell 

Enterprise Business Analyst and Educator 

Owen Crowley 

President, Exogene Corp. 

Phil Vitkus 

Independent BPM Consultant 

Nancy Bilodeau 

Director Loyalty Partner Program, Sears Holdings 
Corporation 


Completing the CBOK® 

A final edit was performed by a professional editor to ensure format consistency, 
grammatical correctness, and spelling accuracy. In addition, graphics were revised 
by a professional graphics artist to ensure consistency and quality. 

Vendor references 

In BPM and BPMS, many vendors and research firms create reference models and 
use different terminology in both their everyday discussions and in these models. 
ABPMP has NOT adopted any specific research firms’, vendors’, or consulting firms’ 
models. Instead, we use a variety of these models throughout the CBOK to acquaint 
the reader with different models and to show that the choice of model is not so 
important: rather, what’s important is that the reader’s company either select one 
model for each issue (such as BPM maturity and process management maturity) and 
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use that model consistently, or that they understand that various models are in use 
and adjust accordingly. 

The CBOK® 

Future versions 

BPM and BPMS are changing rapidly, and any discussion will need to be revised and 
updated continuously. To do this, ABPMP will release updates to chapters on an 
ongoing basis. These will be available on the ABPMP website to ABPMP members 
and others who purchase annual CBOK® licenses. 

We recognize that, regardless of the steps we have put in place to deliver a quality 
product, there may be topics that members would like added and points that might 
be more fully discussed. The goal is to provide a foundation or framework for the 
BPM industry and help our members and other readers obtain a comprehensive 
perspective of the topics and issues that they must deal with to deliver 
improvement and transformation. 

Readers who would like to see additional topics or discussions in future versions are 
invited to send all suggestions or recommendations for changes to ABPMP at 
Edcomm@abpmp.org 

Comments 

Please send comments to ABPMP through our website, and let us know if there are 
any topics you believe we should include or if you have disagreements with the 
association’s point of view. Your comments will be used as a foundation for future 
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Defining a Business Process Management Professional 

The following is an excerpt from an article written by Brett Champlin, past President 
of the Association of Business Process Management Professionals ( ABPMP '), for BPM 
Strategies, October 2006 edition. 

Business Process Management Professionals 

At several recent BPM conferences, I have asked audiences of several hundred 
attendees to give me a show of hands, first for "Who is from IT?" Generally about 30- 
45% of the hands go up; then, "Who is from the Business side?" Another 30-45%; 
then, "Who here is like me, stuck in the middle?" Nearly the entire group raises their 
hands, generally emphatically. This is telling. Many of us who work in process 
management, process redesign, process performance analysis, process automation, 
and the like, are conflicted. Are we business practitioners who have to understand 
how to leverage IT to manage by process or are we IT practitioners who have to 
understand the business in order to fully utilize the capabilities of new IT solutions? 

BPM is both a management discipline and a set of technologies that support 
managing by process. A convergence of technologies for workflow, enterprise 
application integration (EAI), document and content management, business rules 
management, performance management and analytics among other have been 
brought to bear with a focus on supporting process based management. A few years 
ago BPM software vendors were focused on the execution layer of the technology 
stack. Today they are delivering BPM Suites with a full range of features and 
functions to support process managers and analysts as well as technology 
developers. 

Recent research studies confirm that Business Process Management (BPM) is 
rapidly evolving as the dominant management paradigm of the 21 st Century. An 
April 2005 BPMG study found that "...the practice of BPM as a primary means to 
manage business has already gained substantial adoption" and "...more than 80% of 
the world’s leading organizations are actively engaged in BPM programs, many of 
these on a global scale." An APQC benchmarking study completed in March 2005 
found that "BPM is the way best-practice organizations conduct business." That 
study also examined proven strategies, approaches, tools and techniques (including 
business process frameworks and maturity models) employed by world-class, 
process-focused enterprises and found that while "technology, by itself, does not 
constitute Business Process Management, much of the promise of BPM initiatives 
will not be realized without powerful, flexible and user-friendly IT solutions to 
support them." 

Business Process Management and Performance Management are merging as more 
and more process management groups begin to recognize the organization as a 
system of interacting processes whose performance must be balanced, and that 
must be the focus of fulfilling strategies. Conversely, more and more of those 
engaged in enterprise performance management are realizing that it is the 
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performance of the business processes, not the organizational functional units or a 
set of assets, that has to be their central focus in order to gain the true benefits of a 
performance management initiative. Sophisticated and powerful new technologies 
are central to successful and sustainable programs for both of these disciplines, and 
integrating the information delivery capabilities as well as management methods is 
critical to moving up the scale of maturity in deploying these practices. 

Along with this business process management revolution, new organizational 
structures and roles are emerging and a new genre of professionals is emerging to 
support these practices. Yet, business schools don’t teach us how to manage by 
process. No textbooks tell us what roles and responsibilities we need to put in place 
in order to do this kind of work. There is no authoritative research to indicate 
exactly how we should structure our governance and operations to do this kind of 
work. In fact, what research there is indicates that there is no "one-size-fits-all" 
solution. Various models and roles have proven successful in various industries, 
none showing any clear advantage over the other. One thing that is clear is that 
managing by process and adapting new information systems tools to support those 
activities is a successful strategy that brings tremendous advantage to those 
businesses that adopt it. And, it seems that the more broad-based the process 
management initiative is in the organization, the more effective it is and the more 
value it adds. 

There seem to be as many companies whose BPM efforts are driven by their IT 
organizations as there are those whose BPM programs are being led by core 
business areas. Likewise, there seem to be two major approaches: those that are 
more project-oriented versus those that view BPM as a continuous process 
improvement and transformation effort. These different models generate roles and 
responsibilities with widely varying titles and alignments of responsibilities, yet all 
are process-management focused. 

Within the Association of BPM Professionals, our membership shows a diversity of 
titles that reflect these divergent approaches to process management. We have well 
over 150 different titles represented in our database, although there are clusters 
around some of the titles like Manager, Director, VP, Analyst, Consultant, and 
Architect, usually preceded or followed by Process, BPM, Process Improvement, 
Process Innovation, and the like. 

One role that is particularly significant in BPM programs is that of the Process 
Owner. Depending on whether the organization restructures around cross- 
functional business processes, creates a matrix-managed organization, appoints 
functional managers to take on a dual role, or relies on a cross-functional council of 
managers to oversee core business processes, it will ensure that someone takes on 
the responsibilities of a "Process Owner" for each of the organization’s key 
operational processes. This role seems to be one of the critical success factors in 
effective process-oriented organizations. 

An organizational factor that seems to reflect the evolution or maturity in 
organizations implementing BPM is the existence of a specialized group that is 
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recognized as the process specialists. Many begin with a BPM "Center of Excellence” 
or similar group that provides to the organization process modeling, analysis, 
design, and project expertise along with standard tools, methods and techniques 
and acts as an internal consulting group. A more mature or experienced process- 
oriented organization will have a process management governance group or 
"Process Management Office” that oversees the organization’s portfolio of processes, 
and aligns, prioritizes, and authorizes transformation efforts. And some companies 
may have both types of groups working together. These groups are staffed with 
process management professionals with a wide range of titles and alignment of 
responsibilities. 

While there seem to be many successful models for implementing BPM in 
organizations, one thing they all have in common is the many new roles with new 
sets of skills and responsibilities all centered on BPM. This is an emerging group of 
professionals whose work is essential to 21 st century business: the business process 
professional. Judging from the members of ABPMP, they are generally highly 
educated (67% have a bachelor or advanced degree) and have a significant amount 
of experience (9.9 years average) working in process improvement and redesign. 

Some of the more common roles are: 

• Business Process Analyst 

• Business Process Engineer 

• Business Process Architect 

• Business Process Manager 

• Business Process Consultant 

• Business Process Manager 

• Business Process Owner 

• Business Analyst 

• Business Systems Analyst 

• Manager or Director of Business Performance Improvement 

• Manager or Director of Business Process Innovation 

• Process Owner 

• Process Officer 


These titles and their variants cover the majority of the new roles and 
responsibilities in process-managed organizations. Regardless of the roles or 
organizational structure, they generally are responsible for the same sets of 
activities: Process Modeling, Process Analysis, Process Design, Process Change and 
Transformation, Process Implementation, Process Monitoring and Control, and 
Process Performance Improvement. Some of these roles may be staffed in IT 
organizations and some in business disciplines. Many organizations are staffing with 
cross-discipline groups combining both IT and business knowledge or with people 
who have served in both IT and business units, bringing a depth of knowledge and 
range of skills that transcend traditional boundaries. Many have found that 
combining people who have general consulting-type knowledge and skills with 
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others who have a depth of business-specific knowledge is a successful strategy for 
BPM efforts. 

There is a new professional in the business world today, the business process 
professional. The work they do is critical to the future of competitive organizations. 
And, even though there is no single or clear model that one can adopt, it doesn’t 
diminish the need for more skilled and motivated people to do this work. 

Eventually, universities will come out with well-researched and structured models 
based on some of the most visible success stories. In the meantime, businesses can’t 
wait for someone to tell them the “best" way to do this; they have to do this work 
today, and there just aren’t enough knowledgeable, skilled people to go around. 
Successful organizations are finding that to staff these groups, they have to invest in 
training and development. Some are building their own curricula and training 
programs and bringing entry-level people on board to work closely with the few 
talented BPM professionals they do have. Others are sending managers, project 
leaders, and systems analysts to training, such as the BPM-Institute certificate 
program, to begin to build the requisite knowledge and skills. This situation will 
likely continue to be the most viable approach to building process organizations for 
the near future. 

The mission of ABPMP and EABPM is to engage in activities that promote the 
practice of business process management, to develop a common body of knowledge 
in this field, and to contribute to the advancement and skill development of 
professionals who work in this discipline. ABPMP and EABPM’s local chapters 
produce periodic events featuring case studies and presentations about BPM topics, 
which provides an inexpensive continuing education program for their members. 
ABPMP and EABPM have an education committee that is developing a BPM Common 
Body of Knowledge. Following that, we will produce recommended curricula for 
academic and training programs. We intend to create a set of criteria to evaluate 
training programs and a process for formal endorsement of training providers and 
academic programs. Following that, we will develop a professional certification 
program to certify practitioners and expert business process management 
professionals. 

I think working in BPM at this time is the most exciting and valuable business 
experience managers and professionals can get today. I see Business Process 
Management professionals as the new training background for future business 
leaders today, much as project management was 15 years ago. However, we need to 
develop some baseline standards, minimum qualifications, and some reasonable 
path for becoming a professional in this area. If you are working in process 
management, join others in developing the profession — join ABPMP today. Together 
we can build a new professional discipline that will create the future. 
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The Association of Business Process Management Professionals 

Background on ABPMP 

The Association of Business Process Management Professionals (ABPMP) is a non- 
profit, vendor-independent professional organization dedicated to the advancement 
of business process management concepts and practices. ABPMP is practitioner- 
oriented and practitioner-led. 

ABPMP has local chapters in several US areas, and many more are forming in the US 
and internationally. Individuals wishing to participate who are not located near an 
existing local chapter are urged to investigate the feasibility of starting a chapter in 
their locality. When not affiliated with a local operating chapter, members will be 
part of the Members At-Large chapter, which has its own elected officers and 
participates in ABPMP activities as any other chapter would. 

ABPMP is governed by an elected Board of Directors. Each chapter president is an 
ex-officio, voting member of the International Board of Directors. ABPMP also has a 
Board of Advisors made up of some of the most well known authors, practitioners, 
and thought-leaders in the field. These advisors are volunteers who periodically 
offer advice to the chapters and Board of Directors concerning the industry and how 
ABPMP can best serve its members. 

ABPMP is affiliated with other professional organizations, including the European 
Association of Business Process Management (EABPM), which administers the 
ABPMP certification process and translates the BPM CBOK® into the French and 
German languages. Additional affiliations are described in the Appendix labeled 
"Reference Disciplines." 

For more information on ABPMP, please see our website at www.abpmp.org. For 
more details about EABPM see the website at www.eabpm.org 

Core Mission / Values / Operation 

The Association of Business Process Management Professionals is a non-profit, 
vendor-neutral professional organization dedicated to the advancement of business 
process management concepts and practices. ABPMP is practitioner-oriented and 
practitioner-led. 

Vision 

The vision of the ABPMP is to 

• Be the center for the community of practice in business process management 

• Provide the leading professional society for business process management 
professionals 

• Define the discipline and practice of business process management 

• Recognize, acknowledge and honor those who make outstanding 
contributions to the business process management discipline. 

Mission 

The mission of ABPMP is 
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• To engage in activities that promote the practice of business process 
management, 

• To develop a Common Body of Knowledge for BPM, and 

• To contribute to the advancement and skill development of professionals 
who work in the BPM discipline. 

Operation 

The ABPMP produces educational and networking events for continuing education 
and sharing of best practices, new ideas, and experiences of its members and 
professional colleagues. Information on these events can be found on the ABPMP 
website at www.abpmp.org. 

Code of Ethics 

ABPMP is committed to the highest standard of professional ethics and believes that 
Business Process Management Professionals should 

• Conduct their professional and personal lives and activities in an ethical manner 

• Recognize a standard of ethics founded on honesty, justice and courtesy as 

principles guiding their conduct and way of life 

• Acknowledge that there is an obligation to practice their profession according to 

this code of ethics and standards of conduct. 

All ABPMP members must agree to and sign the following code of ethics and 
statement of professional conduct: 

The keystone of professional conduct is integrity. Business Process Management 
Professionals will discharge their duties with fidelity to the public, their employers, 
and clients with fairness and impartiality to all. It is their duty to interest themselves 
in public welfare, and be ready to apply their special knowledge for the benefit of 
humankind and the environment. 

I acknowledge that 

• I have an obligation to society and will participate to the best of my ability in 
the dissemination of knowledge pertaining to the general development and 
understanding of business process management. Further, I shall not use 
knowledge of a confidential nature to further my personal interest, nor shall I 
violate the privacy and confidentiality of information entrusted to me or to 
which I may gain access. 

• I have an obligation to my employer/client whose trust I hold. Therefore, I 
shall endeavor to discharge this obligation to the best of my ability, to guard 
my employer/clients interests, and provide advice wisely and honestly. I 
shall promote the understanding of business process management methods 
and procedures using every resource available to me. 

• I have an obligation to my fellow members and professional colleagues. 
Therefore, I shall uphold the high ideals of ABPMP as outlined in the 
Association Bylaws. Further, 1 shall cooperate with my fellow members and 
shall treat them with honesty and respect at all times. 
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• I accept these obligations as a personal responsibility and as a member of 
this Association. I shall actively discharge these obligations and I dedicate 
myself to that end. 

Standards of Conduct 

These standards expand on the Code of Ethics by providing specific statements of 
behavior in support of the Code of Ethics. They are not objectives to be strived for; 
they are rules that no professional will violate. The following standards address 
tenets that apply to the profession. 

In recognition of my professional obligations, I shall 

• Avoid conflict of interest and make known any potential conflicts 

• Protect the privacy and confidentiality of all information entrusted to me 

• Accept full responsibility for work that I perform 

• Ensure that the products of my work are used in a socially responsible way, to 
the best of my ability 

• Support, respect, and abide by the appropriate local, national, and international 
laws 

• Make every effort to ensure that I have the most current knowledge and that the 
proper expertise is available when needed 

• Share my knowledge with others and present factual and objective information 
to the best of my ability 

• Be fair, honest, and objective in all professional relationships 

• Cooperate with others in achieving understanding and in identifying problems 

• Protect the proper interests of my employer and my clients at all times 

• Take appropriate action in regard to any illegal or unethical practices that come 
to my attention; I will bring charges against any person only when I have 
reasonable basis for believing in the truth of the allegations and without any 
regard to personal interest 

• Not use knowledge of a confidential or personal nature in any unauthorized 
manner or to achieve personal gain 

• Never misrepresent or withhold information that is germane to a problem or 
situation of public concern nor will I allow any such known information to 
remain unchallenged 

• Not take advantage of a lack of knowledge or inexperience on the part of others 

• Not use or take credit for the work of others without specific acknowledgement 
and authorization 

• Not misuse authority entrusted to me. 

We are always concerned about the quality of our information and we have taken 
care to vet every discussion in this CBOK through multiple reviews by top BPM 
professionals. Please contact us with comments on this version of our BPM Common 
Body of Knowledge. Information on the ABPMP Association is provided on our 
website at http://www.abpmp.org/ 

ABPMP International Board of Directors 
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1.0 Introduction 

What is the Guide to the BPM CBOK ? 

As BPM business practices, management discipline, and enabling technologies 
mature, our understanding of BPM also matures. There is a tremendous body of 
knowledge on BPM, including hundreds of books, articles, presentations, process 
models and best practices, which are based upon practice experience, academic 
study, and lessons learned. The trend in BPM today focuses on enterprise-wide, 
cross-functional processes that add value for customers (both internal and 
external). Business processes define how enterprises perform work to deliver value 
to their customers. The purposeful management of these processes creates stronger 
business practices that lead to more effective workflow, greater efficiencies, more 
agility, and ultimately higher returns on stakeholders’ investments. 

It would be impractical to collect and present in a single volume all of the available 
knowledge on the practice of BPM. This guide to the BPM Common Body of 
Knowledge is designed to assist BPM professionals by providing a comprehensive 
overview of the issues, best practices, and lessons learned as collected by the 
ABPMP and affiliated associations. BPM is a constantly evolving discipline. Version 

3.0 of the ABPMP BPM CBOK® provides a basic understanding of BPM practice along 
with references to the BPM community and other valuable sources of information. 
BPM professionals are encouraged to use this guide in conjunction with a variety of 
other sources of information, get involved in the BPM community, and expand and 
share their knowledge on the practice of BPM. 

Because the term Business Process Management (BPM) is used so frequently 
throughout this publication, here follows its definition as applied here: 


Business Process Management (BPM) is a management 
discipline that integrates the strategy and goals of an 
organization with the expectations and needs of customers by 
focusing on end-to-end processes. BPM comprises strategies, 
goals, culture, organizational structures, roles, policies, 
methodologies, and IT tools to (a) analyze, design, implement, 
control, and continuously improve end-to-end processes, and 
(b) to establish process governance. 


1.1 Purpose of the Guide to the BPM CBOK® 

This Guide to the BPM CBOK® provides a basic reference for BPM practitioners. The 
primary purpose of this guide is to identify and provide an overview of the 
Knowledge Areas that are generally recognized and accepted as good practice. It 
includes roles and organizational structures as well as provisions to steer a process- 
driven organization. The Guide provides a general overview of each Knowledge Area 
and a list of common activities and tasks associated with each Knowledge Area. It 
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also provides links and references to other sources of information that are part of 
the broader BPM Common Body of Knowledge. 

This Guide is also intended as a springboard for discussions among BPM 
professionals. Often, a discipline such as BPM finds different groups using language 
in different ways, resulting in terminology or conflicting definitions that can confuse 
discussions on the topic. One purpose of the Guide to the BPM CBOK® is to 
encourage the use of a common, agreed-upon vocabulary for the BPM discipline. 

In addition, the Guide reflects the fundamental knowledge required of a BPM 
professional. Any assessment or professional certification in the field would require 
a demonstrated understanding of the core BPM concepts outlined in the knowledge 
areas, as well as the ability to perform the activities and tasks identified within 
them. This Guide to the BPM CBOK® is the basis for developing examination 
questions for the exam that individuals must pass to become a Certified Business 
Process Professional (CBPP®). 

1.2 Status and Feedback 

As the Common Body of Knowledge in BPM evolves and expands with additional 
information and experience, so too will this Guide to the BPM CBOK®. Version 2.0 
was published in English, German, and Portuguese. Readers of Version 2.0 provided 
valuable feedback, which was taken into consideration for the development of this 
version. The purpose of this third release of the Guide is to further define the scope 
and structure of the Guide. Version 3.0 was enhanced by an international 
collaboration between ABPMP and the European Association of Business Process 
Management. It will be published in French, Japanese, and Arabic, in addition to the 
previous languages. 

The development and management of the Guide to the BPM CBOK® is the 
responsibility of the Education Committee within the ABPMP. The Education 
Committee welcomes any feedback in order to improve the BPM CBOK® and gauge 
its acceptance by the community of BPM professionals. 

Membership support and enthusiasm of BPM experts are critical to the success of 
this Guide, the development of the Certification process, and the promulgation of 
knowledge on BPM topics. To support membership involvement in the evolution of 
the BPM CBOK®, the Education Committee has formed a subcommittee which 
focuses on the support and maintenance of this Guide. 

1.3 CBOK® Organization: Summary of Chapters 

This Guide to the BPM CBOK® is organized in BPM core areas or chapters, as 
outlined in Figure 1-1. These BPM core areas are segmented into a broader, 
organizational-oriented perspective and a process perspective. BPM core areas 
reflect BPM capabilities that may be considered by an organization implementing 
Business Process Management. 

BPM concepts are covered in the Business Process Management chapter, which sets 
the stage for all of the BPM core areas. 
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Figure 1. Core Areas of BPM and CBOK Organization 


The Process Modeling, Analysis, Design, Implementation, Performance Management, 
and Transformation BPM core areas cover critical BPM activities and skill sets. Many 
of the BPM core areas are enabled and supported by BPM Technologies. Please note 
that there is no dedicated CBOK® chapter for process implementation, since IT- 
related aspects are covered in the BPM Technologies chapter and organizational 
aspects are covered in the change management section of the Process Performance 
Transformation chapter. 

The larger BPM environmental issues and how the practice of BPM relates to other 
organizational dimensions, such as governance and strategic planning, are 
addressed in the Process Management Organization and Enterprise Process 
Management chapters. 

1.4 Overview of Chapters 

Business Process Management (chapter 2) 

The Business Process Management chapter focuses on the concepts of BPM, such as 
key definitions, end-to-end process, customer value, and the nature of cross- 
functional work. Process types, process components, the BPM lifecycle, along with 
critical skills and success factors are introduced and explored. This chapter defines 
BPM and provides the foundation for exploring the Core Areas of BPM. 

Process Modeling (chapter 3) 

Process Modeling includes a critical set of skills and processes that enable people to 
understand, communicate, measure, and manage the primary components of 


29 


Copyright ABPMP International 


Chapter 1. Guide to the CBOK® 


business processes. The Process Modeling Core Area provides an overview of these 
skills, activities, and key definitions, along with an understanding of the purpose and 
benefits of process modeling, a discussion of the types and uses of process models, 
and the tools, techniques, and modeling standards. 

Process Analysis (chapter 4) 

Process Analysis involves an understanding of business processes, including the 
efficiency and effectiveness of business processes. This chapter explores process 
analysis purpose, activities to support process decomposition, and analytical 
techniques along with roles, scope, business context, rules, and performance 
metrics. The focus is on understanding current-state processes with a view to 
achieving improvement in the future state. A variety of process analysis types, tools, 
and techniques are included within this Knowledge Area. 

Process Design (chapter 5) 

Process design involves creating the specifications for business processes within the 
context of business goals and process performance objectives. It provides the plans 
and guidelines for how work flows, how rules are applied, and how business 
applications, technology platforms, data resources, financial, and operational 
controls interact with other internal and external processes. Process design is the 
intentional and thoughtful planning for how business processes function and are 
measured, governed, and managed. This Core Area explores process design roles, 
techniques, and principles of good design, along with an exploration of common 
process-design patterns and considerations such as compliance, executive 
leadership, and strategic alignment. 

Process Performance Measurement (chapter 6) 

Process performance measurement is the formal, planned monitoring of process 
execution and the tracking of results to determine the effectiveness and efficiency of 
the process. This information is used to make decisions for improving or retiring 
existing processes and/or introducing new processes in order to meet the strategic 
objectives of the organization. Topics covered include importance and benefits of 
performance measurement, key process performance definitions, monitoring and 
controlling operations, alignment of business process and enterprise performance, 
what to measure, measurement methods, modeling and simulation, decision 
support for process owners and managers, and considerations for success. 

Process Transformation (chapter 7) 

Process transformation addresses process change. Process changes are discussed in 
the context of a process lifecycle from planning to implementation. Various process 
improvement, redesign, and reengineering methodologies are explored, along with 
the tasks associated with 'construction,' quality control, and the introduction and 
evaluation of new processes. The topic of organizational change management, which 
is critical to successful process transformation, is also discussed here: it includes the 
psychological background of change management and success factors for change. 
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Process Management Organization (chapter 8) 

The process management organization knowledge area addresses the roles, 
responsibilities, and reporting structure to support process-driven organizations. A 
discussion of what defines a process-driven enterprise, along with cultural 
considerations and cross-functional, team-based performance is provided. The 
importance of business process governance is explored, along with a variety of 
governance structures and the notion of a BPM Center of Excellence (COE) or 
Competency Center. 

Enterprise Process Management (chapter 9) 

Enterprise process management is driven by the need to maximize the results of 
business processes consistent with well-defined business strategies and functional 
goals based on these strategies. Process portfolio management ensures that the 
process portfolio supports corporate or business-unit strategies and provides a 
method to manage and evaluate initiatives. The Enterprise Process Management 
Knowledge Area identifies tools and methods to assess process management 
maturity levels, along with required BPM practice areas that can improve a BPM 
organization state. Several Business Process Frameworks are discussed, along with 
the notion of process integration — i.e., interaction of various processes with each 
other and with models that tie performance, goals, technologies, people, and 
controls (both financial and operational) to business strategy and performance 
objectives. The topics of process architecture and best practices in enterprise 
process management are explored. 

BPM Technology (chapter 10) 

BPM is a technology-enabled and supported management discipline. This chapter 
discusses the wide range of technologies available to support the planning, design, 
analysis, operation, and monitoring of business processes. These technologies 
include the set of application packages, development tools, infrastructure 
technologies, and data and information stores that provide support to BPM 
professionals and workers in BPM-related activities. Integrated Business Process 
Management Suites (BPMS), process repositories, and stand-alone tools for 
modeling, analysis, design, execution and monitoring are discussed. BPM standards, 
methodologies, and emerging trends are also covered. 

1.5 Benefits of BPM 

To gain commitment and momentum for the introduction and further development 
of BPM, the book summarizes some important potential benefits and advantages for 
different stakeholders, particularly four important groups of stakeholders who may 
benefit directly or indirectly from BPM. This list should not be read as a roadmap, 
but as the types of opportunity available, depending on the company's maturity and 
the energy it decides to give the BPM development. 
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Benefits of BPM for the 


Enterprise 

Customer 

Management 

Actor 

Clear ownership 
for continuous 
improvement 

Improved 
processes will 
positively impact 
customer 
satisfaction 

Making sure that all 
the activities 
realized along a 
process add value 

Security and 
awareness for 
actors 

Agile response to 

measured 

performance 

Mobilizing staff on 

stakeholders 

expectations 

Optimizing 
performance all 
along the process 

Better 

understanding of 
'the whole picture' 

Performance 
measurement 
benefits cost and 
quality 

Keeping control 
on commitments 
to the customer 

Improved planning 
and projections 

Clarifying the 
requirements of a 
workplace 

Monitoring 

improves 

compliance 


Overcoming the 
obstacles of 
departmental 
borders 

Defining precisely 
the appropriate set 
of tools for actors 

Visibility, 

understanding, and 
change readiness 
improve agility 


Facilitating internal 
and external 
benchmarking of 
operations 


Access to 
information 
simplifies process 
improvement 


Organizing alerts 
levels in case of 
incident and 
analyzing the 
impacts 


Assessing process 
costs facilitates 
cost control and 
reduction 




Competence, 
consistency and 
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adequacy 




Sustaining the 
knowledge 





Table 1. Benefits of BPM 


1.5.1 Benefits to the Enterprise 

Clear ownership and responsibility for continuous improvement 

If responsibilities for processes are clearly assigned (e.g. to process owners), a 
lasting commitment to maintain and permanently improve processes can be 
ensured. If the customer does not get what they want or if internal goals are not 
achieved, clear-cut responsibilities ensure quick and well mapped-out actions. 

Agile response to measured performance 

BPM can feed day-to-day information control systems that measure process 
performance. Organizations with robust BPM capabilities can then respond rapidly 
to deviations in measured performance. 

Performance measurement benefits cost and quality 

Active measurement of process performance reinforces and benefits cost control 
and quality. Without performance measurement, organizations will not have the 
capability to achieve optimal performance. 

Monitoring improves compliance 

Most organizations face internal or external compliance risk through inaction or 
improper response to events. Monitoring process execution against compliance 
requirements can greatly mitigate such risks. Automated monitoring coupled with 
quality management and clear procedures and authorities can further mitigate 
compliance risk, while at the same time reducing compliance cost and improving 
overall quality. 

Visibility, understanding, and change readiness improves agility 

Without process management, organizations become bogged down in the 
unknowns, and can be blindsided by unaccounted internal or external changes. 
Organizations that document, manage, and measure their processes are prepared 
for continuous improvement and are better positioned to recognize and stay ahead 
of challenges. 

Access to useful information simplifies process improvement 

Having immediate access to process repositories and best practices facilitates and 
accelerates the improvement of processes or the effective reaction to environment 
changes and new rules and regulations. 
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Assessing costs of processes facilitates cost control and reduction 

Knowing all the activities in a process facilitates assessing direct costs of processes 
and identifying the most effective ways to reduce them. Additionally this helps to 
better price delivered products and services. 

Competence consistency and adequacy 

Knowing all the activities executed in an organization enables competence 
consistency, standardization, and adequacy. This is also a foundation for assessing 
and managing core and competitive capabilities. 

Documenting operations and sustaining the knowledge 

The knowledge of activities and tasks performed by each entity of an organization 
is the basis for describing procedures (how the business is run). This set of 
documents provides a repository of knowledge useful to ensure its sustainability all 
around the company. It is an important part of the knowledge management of an 
organization. 

1.5.2 Benefits to Customers 

Improved processes will positively impact customer satisfaction 

The improvement of processes helps to meet time expectations, increase the quality 
of products and services, and opens the possibility to reduce prices through cost 
reduction. All this leads to higher customer satisfaction. 

Mobilizing staff on stakeholders' expectations 

A process is designed to meet stakeholder requirements. It highlights all the actors 
who contribute to stakeholder satisfaction and allows each of them to recognize the 
purpose of their work, giving sense to the work they do. 

Keeping control on commitments to the customer 

Steering the processes gives control to individuals to regularly measure 
performance and, if necessary, to correct excesses in each part of the business. This 
allows individuals to focus on the customer’s benefit. 

1.5.3 Benefits to Management 

Making sure that all the activities realized along a process add value 

A process contains a set of activities that succeed one another and are linked. Every 
activity made has to bring an added value to the process. The identification of the 
various activities enables questions about their value, and if value cannot be found, 
it is advisable to delete them. 

Optimizing performance all along the process 

The process design helps staff to learn and master all of the necessary contributions. 
It helps focus performance analyses on each contributor and finds specific 
organizational and technological ways to improve the process. In the end, changes 
will reduce time and cost, while improving quality. 
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Improved planning and projections 

Visible and measureable processes augment traditional sources of planning data. 
Leadership can take organizational performance and change plans into account in 
medium and long-term planning. 

Overcoming the obstacles of departmental borders 

Many companies are structured according to vertical silos where each branch 
optimizes its own activities. A process-based approach highlights the operational 
linkages between departments, necessary to effectively satisfy every request. A 
process view helps an organization focus on interactions and handoffs that will 
allow it to improve its overall processes and effectiveness. 

Facilitating internal and external benchmarking of operations 

A process approach based on activities and not on organization structures enables 
the comparison of different ways to achieve a common objective. In addition, Key 
Performance Indicators (KPIs) attached to the process make it easier to compare the 
relative performance of different solutions. These internal or external assessments 
facilitate to choose the best practices. 

Organizing alerts levels in case of incident and analyzing the impacts 

The process owner is in charge of the day-to-day execution of their processes. 

Within various process teams, the process owner must develop ways and means for 
early detection of dysfunctions that emerge and ensure organized and focused ways 
to communicate with others, depending on the nature of the situation. 

1.5.4 Benefits to Actors 

Security and awareness for actors 

Knowing the importance of an individual’s contributions and performance 
according to goals and indicators creates awareness of the work performed, clarifies 
the importance of each position, and helps to build the importance of the customer’s 
experience. 

Better understanding of 'the whole picture' 

Documented and well-understood processes promote awareness of the 
interdependence among activities, and therefore the importance of compliance as a 
key success factor for the overall business success. Designing processes requires 
analyzing existing practices and offers the opportunity to identify any gaps in the 
business documentation (non-described or outdated procedures, etc.). 

Clarifying the requirements of a workplace 

The knowledge of the work performed provides the ability to design training 
modules adjusted to the needs of the workplace. 

Defining precisely the appropriate set of tools for actors 

Knowing processes in details help accurately identify all the necessary resources 
consistent in quantitative (workload) and qualitative (skills) terms. It optimizes the 
workplace and its documentation. 
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1.6 BPM Overview 

BPM provides a means to focus on results as well as course of action. Figure 2 
illustrates three broad applications for BPM. 


Business Process Management (BPM) 

Business Process 

Enterprise Process 

Continuous 

Improvement 

Management 

Refinement 

Singular Initiative 

Application of BPM 

Sustained feed-back 

(mostly project driven) 
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• BPM methodology (lifecycle) 

• Six Sigma 

• Lean Management 

• TQM 

• Business Reengineering 

• Performance Improvement 

• Activity based costing 

To determine the standard achieved 



Figure 2. Views of BPM 


Initiatives can be limited in scope, such as a project that is targeted on Business 
Process Improvement (BPI). This can be achieved by the application of the BPM 
Lifecycle as described in this Guide or by applying other methodologies like Lean 
Management or Six Sigma. 


Business Process Improvement (BPI) is a singular initiative 
or project to improve the alignment and performance of a 
particular process with the organizational strategy and 
customer expectations. BPI includes the selection, analysis, 
design, and implementation of the (improved) process. 


BPM can also mean a holistic system as the outcome of initiatives or projects. This 
result, called Enterprise Process Management (EPM), includes the strategy, 
values and culture, structures and roles, and a whole set of end-to-end processes 
with their associated goals and indicators, IT, and people. The degree of progress 
reached can be assessed as Process Management Maturity Level. 
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Enterprise Process Management ( EPM ) is the application of 
BPM principles, methods, and processes to an individual 
enterprise. EPM (a) assures the alignment of the portfolio and 
architecture of end-to-end processes with the organization’s 
strategy and resources and (b) provides a governance model 
for the management and evaluation of BPM initiatives. 


BPM can also be seen as a Continuous Refinement, which can be achieved by the 
application of a day-to-day feedback control system to permanently improve the 
quality of single processes and the Enterprise Process Management System. 


Business Process Continuous Refinement is the sustained 
approach to make specified processes more efficient and 
effective by applying a concurrent and responsive feedback 
control system. 
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Foreword by Janelle Hill, VP Gartner, Inc. 

Gartner's Vision for Business Process Management 

During the past 100 years, breakthroughs in process management have been 
fundamental to the progress of corporations, industries, and economies. Process and 
quality discipline transformed Japan's fortunes in the decades after World War II, 
which shows the economic muscle that better process management can deliver. 

In 2011, we are at the beginning of another era in process thinking — a period that, 
in Gartner’s view, will be distinguished by operationally resilient processes, not just 
standardized and efficient processes. In Gartner’s view "operational excellence" 
should no longer simply be measured by inward-looking, efficiency-oriented 
metrics. Instead, key tenets of BPM emphasize process visibility, accountability, and 
adaptability in order to continually optimize results and better meet the challenges 
of a globally diverse business environment. 

To meet these challenges, enterprises need to improve their ability to anticipate and 
respond to shifting market and customer demands. Businesses want their 
operations to become more resilient, especially given the frequency of disruptive 
events in a global economy. Yet, despite 'business agility’ having been the mantra of 
BPM for the last 10 years, few organizations have actually achieved this goal. 
Although leaders in BPM are delivering more frequent changes to their processes 
and have fostered a culture of continuous process improvement, their processes are 
still not designed for change. Implementing change continues to be difficult, often 
requiring deep technical skills. More typically, IT delivery cycles rather than the 
pace of business still control process adaptability. 

There are many reasons for this lack of achievement. One factor is that few 
organizations have yet identified those processes that truly need to become more 
agile. Few business leaders have asked themselves questions such as: 

• What are the signals in our work that would indicate that operational change 
might be needed? And how can we monitor the environment for those 
signals? 

• What events (internally and externally triggered) would drive us to change 
how work is done? 

• What aspects of work specifically need to change and how often? 

• Who should decide that change is appropriate and what specific change is 
needed? 

• How can we communicate the desired change and ensure that it is 
implemented? 

• How can we know if the change achieves the desired outcome? And if it 
doesn't, could we undo the change easily? 

Furthermore, our research finds that most organizations continue to focus on small 
improvements to structured processes, when the bigger opportunity for process 
differentiation is in knowledge-intensive work. Work performed by knowledge 
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workers is largely unstructured: it is non-routine and not performed in a 
predictable, sequential fashion. 

Knowledge work involves research, analysis, high levels of expertise and judgment, 
collaboration, risk assessment, and creativity, in addition to investigative, 
negotiating, and communication skills and more. The characteristics of knowledge 
work have largely precluded it from the benefits of software automation for 
decades. This can’t continue. Why? Because leading economies around the world 
depend on knowledge worker success. The world’s leading economies are all 
services-based — not agricultural- or industrial-based anymore. Services-based 
industries depend on harnessing knowledge. Therefore, organizations should start 
to apply process management techniques to better support and coordinate these 
more unstructured work domains. 

Yet the exposure is high because knowledge work is inherently complex and will 
challenge traditional process thinking. Applying BPM to knowledge-centric domains 
does not mean forcing structure and routine onto these areas. Instead, advanced 
BPM-enabling technologies like explicit models, real-time data feeds, virtualization, 
social media, and statistical analysis can be incorporated to coordinate (not 
automate) resource interactions, to prioritize work, and make the process and 
individual work efforts transparent. By incorporating modern BPM techniques 
(such as empowering those closest to the customer experience of the work) and 
technologies, businesses can become more responsive to shifting market demands. 
BPM is increasingly about fostering effective work habits, not just standardizing 
processes to increase efficiencies. 

Implementing BPM is difficult. The main barriers to any significant change are the 
human ones: inertia and vested interests. And knowledge workers are among the 
most resistant to process improvement. They see it as diminishing their expertise 
and unique insight. However, even this attitude reflects long-held misperceptions of 
process improvement. Process improvement does not always mean making all work 
routine. A lot of BPM effort is about managing the aggregate performance outcome 
of the end-to-end process, not just increasing controls over the individual activities 
and tasks. To achieve operational resilience, the culture and attitudes of the 
organization must also change. The shift in management practices for BPM will not 
come easily but can have far-reaching consequences. 

BPM is a journey, not a destination. The adoption of BPM will strengthen 
competitive advantage in well-positioned companies. BPM-centric companies will 
enjoy increased alignment between operations and strategy, greater operational 
resilience, less-intrusive compliance and of course, increased efficiencies. Begin 
your journey today! 
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2.0 Introduction 

This chapter introduces general Business Process Management definitions and 
concepts, which provide an essential foundation for exploring the remainder of the 
BPM CBOK. 

2.1 What is Business Process Management? 

By definition, Business Process Management is a management discipline that treats 
business processes as assets. It presumes that organizational objectives can be 
achieved through the definition, engineering, control and dedication to continuous 
improvement of business processes. 

While this definition of Business Process Management is a good start, to truly 
understand what BPM is, it must be looked at from a number of perspectives. 
Following is an introduction to several BPM Core Concepts, which will be elaborated 
throughout the remainder of the CBOK. These core concepts are: 

• Business Process Management is a Management Discipline 

• Successfully implemented, Business Process Management is a Core Internal 
Capability 

• Business Process Management addresses the delivery of value to customer 

• Business Process Management addresses end-to-end work and the orchestration 
of activities across business functions 

• Business Process Management addresses What, Where, When, Why and How 
work is done and Who is responsible for performing it 

• The means by which business processes are defined and represented should be 
Fit For Purpose and Fit For Use 

• Business Processes should be managed in a closed-loop cycle to maintain 
process integrity and enable continuous improvement 

• Coordinated and proactive management of business processes requires 
significant investment in internal business capability development 

• Internal capabilities required to support enterprise-wide Business Process 
Management are developed along a Process Maturity Curve 

• A Business Process Management implementation requires the introduction of 
new roles into the organization 

• Business Process Management is not a prescribed framework, methodology, or 
set of tools 

• Technology plays a supporting role, not a leading role in a Business Process 
Management implementation 

• The Implementation of Business Process Management is a Strategic Decision and 
requires strong executive sponsorship for successful implementation 
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2.2 BPM Core Concepts 

2.2.1 Business Process Management is a Management Discipline 

The word "Management" traces to the French word management, "the art of 
conducting, directing," and to the Latin word manu agere, "to lead by the hand." It 
describes the act of leading all or part of an organization through the deployment of 
human, financial, material, and intellectual resources toward fulfillment of stated 
objectives, specifically the maximization of value to customer and thereby a return 
on investment to shareholders. 

A "Discipline" is a body of knowledge that addresses commonly accepted principles 
and practices in a specific subject area. 

A "Management Discipline" therefore is a body of knowledge that addresses the 
principles and practices of business administration. It specifies the principles and 
practices that direct the management of business resources toward stated 
objectives. 

Business Process Management is a Management Discipline which assumes that 
organizational objectives can best be achieved through focused management of the 
organization’s business processes. Defined in this context, Business Process 
Management is a body of knowledge used to establish principles and practices to 
direct the management of resources under this assumption. 

The relevance of introducing Business Process Management as a management 
discipline is threefold: 

• Business Process Management is not a prescribed methodology and toolkit 
consumed wholly by an organization, but instead a Body of Knowledge 
consisting of principles and best practices to guide an organization in the 
development of these elements 

• The Body of Knowledge can be applied to any organization, whether a for-profit, 
non-profit or government entity, for the purpose of directing business resources 
toward strategic objectives 

• Effective management of business processes requires participation from the 
entire organization, from executive management through operational staff and 
across all functions and roles. Successfully implemented, Business Process 
Management becomes engrained in the culture and defines the way business is 
conducted. 

2.2.2 Successfully implemented, Business Process Management is a Core 
Internal Capability 

Implicit in the definition of Business Process Management as a Management 
Discipline is the assumption that organizations that have successfully implemented 
it "have the ability to" effectively manage their business processes. In other words, 
they have developed a Business Process Management capability. 
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A capability in this context is a collection of processes, people, and technologies that 
together provide value toward the achievement of strategic objectives. 

To "have the ability to" effectively manage business processes (to have a Business 
Process Management capability), an organization must possess the processes, 
people, and technologies to do so. To put it another way, an audit of an 
organization's Business Process Management capability should uncover: 

1. Business processes which themselves support the management of business 
processes. For example, an organization should have processes that enable: 

• The definition and design of business processes 

• The build and deployment of business processes 

• The monitoring and control of business process execution 

• The continuous improvement of business processes over time, in spite 
of and in response to internal and external change. 

2. Specific roles (people) that are engaged in the management of business 
processes. These might include, but are not limited to: 

• Process Architects responsible for business process definition and 
design 

• Process Analysts responsible for build, deployment, monitoring and 
optimization of business processes 

• Process Owners responsible for the end-to-end execution of business 
processes against defined performance expectations and ultimately 
the delivery of value to customer. 

3. Specialized technologies deployed to support the management of business 
processes. These technologies provide functionality to: 

• Define business processes in the context of overarching enterprise 
architecture 

• Design business processes for deployment 

• Execute business processes in operations 

• Monitor business processes against performance expectations 

• Analyze business processes to identify and validate improvement 
opportunities 

• Manage and control business process change. 

2.2.3 Business Process Management addresses the delivery of value to 
customer 

The premise of Business Process Management is that organizational objectives can 
be achieved through focused management of business processes. Regardless of 
whether an organization is for-profit, not-for-profit, or a government entity, an 
organization's primary purpose is to deliver value to customer in the form of 
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products and services. This purpose is what all organizational objectives should 
trace to. 

Common in MBA programs is the principle that a for-profit organization’s primary 
purpose is to deliver a return on shareholder investment. This simply will not 
happen (at least not for long) if customers do not perceive value from the 
organization’s product and/or service offerings. So again, the primary purpose of an 
organization is to deliver value to customer in the form of products and services; 
shareholder value is driven from there. 

Simply defined, a business process is a set of activities that transform one or more 
inputs into a specific output (product or service) of value to a customer; and so it 
follows that organizational objectives can be achieved through focused management 
of business processes. 



To some who are first introduced to Business Process Management, or to those who 
may not have a complete understanding of it, the statement "organizational 
objectives can be achieved through focused management of business processes" can 
seem bold. But when the statement is thoroughly decomposed and analyzed, the 
logic tracks: 

• Organizations exist to deliver value to customers in terms of products or 
services 

• All organizational objectives should therefore trace to delivery of value to 
customer 

• Business processes are the vehicles by which products and services are created 
and delivered to customer 

• Business Process Management establishes the means by which business 
processes are managed 

• Therefore Business Process Management is a means for achieving organizational 
objectives. 

Important in this discussion of customer is an understanding that "Customer" is 
entirely dependent upon the business context under analysis. Clearly, the concept of 
customer external to the enterprise is well recognized. For example, 
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• The customers of a tire manufacturer are car manufacturers and people who 
drive cars. 

• The customers of a financial services provider are individuals and business 
entities who save and invest money. 



Figure 4. 


Less obvious is the concept of customer between functions within an enterprise. In 
Figure 4, engines, transmissions, and chassis are engineered in Design, made by 
Manufacturing and put together by Assembly. 

If a context boundary were drawn around the manufacturing organization, and, for 
the sake of analysis, if the manufacturing organization were imagined as an 
independent organizational entity, the customer of the Manufacturing Organization 
is Assembly and the products delivered are Engines, Chassis, and Transmissions. 
The Supplier of the Manufacturing Organization is Design, and the value provided is 
in the form of Design Specifications. 


Supplier 



Figure 5 
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In another example, the Information Systems organization within a Pharmaceutical 
company provides services to the other lines of business. Each of these services is 
delivered to the lines of business through business processes executed by 
Information Technology. This Service Provider / Customer relationship is illustrated 
below. 
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The key takeaway in these examples and a key concept in Business Process 
Management is that business processes deliver value to customer in the form of 
products and services. Business Process Management is about optimizing the means 
by which this value is delivered. 

Organizations successful in business process management instill and foster a culture 
of customer focus at the enterprise level, the functional level, and down through the 
role level. 

2.2.4 Business Process Management addresses end-to-end work and the 
orchestration of activities across business functions 

A Business Function is a classification of work that is done by an organization based 
upon a particular skill or professional expertise. For example, sales, finance, 
manufacturing, supply chain, and customer relationship management are all classic 
business functions. In this context, a business function can be thought of as a "center 
of excellence" — a grouping of people and tools specialized in a specific profession, 
discipline, or area of expertise. 

Considering that a Business Process is a set of activities that transform one or more 
inputs into an output (product or service) of value to a customer, it stands to reason 
that most complex products and services will require contribution from multiple 
business functions. 
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Figure 7. 


The diagram above illustrates 

• Activities performed by Business Functions containing specialized expertise 

• Sequences of activities orchestrated across multiple Business Functions and 
constituting a Business Process. 

The end-to-end management of Business Processes and the controlled orchestration 
of activities across multiple Business Functions is the essence of Business Process 
Management and what differentiates it from traditional Functional Management. In 
today's complex organizations, Business Process Management and Functional 
Management disciplines must cohabit and work together for the organization to 
remain competitively viable. 

• Functional Management ensures execution of the myriad functional disciplines 
required to produce the organization’s products and services. 

• Business Process Management ensures work is coordinated across these myriad 
functions in order to deliver products and services in the most effective and 
efficient manner possible. 

2.2.5 Business Process Management addresses What, Where, When, Why 
and How work is done, and Who is responsible for performing it 

In many organizations, business processes visibility and understanding are often 
facilitated by graphical representations of activities in boxes strung together in 
swim lanes, as in the diagram below. 
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Figure 8. 


Stepping back to examine what information is communicated in this diagram, we 
discover it simply represents "Who does What work." While this information might 
be extremely helpful, it also might leave a number of unanswered questions, such 
as: 

• When is the work done? 

• What material or informational inputs are required? 

• What deliverables and artifacts are produced? 

• Where is the work done? 

• Where are the work deliverables and artifacts stored? 

• Why is the work done? 

• Who benefits from the final output? 

A comprehensively defined business process will address What, Where, When, Why 
and How work is done, and Who is responsible for performing it. A well-structured 
process definition will provide the right amount of visibility and detail to the various 
consumers of this information, potentially across all levels of the organization. 

While swim lane diagrams like the one above are often critical components of a 
complete business process definition, numerous other representations need to be 
included in the full package. 

A small sample of artifacts often created and maintained includes those that 
represent 

• Business context, including the internal capabilities the process supports and 
how the business process contributes to the delivery of products or services to 
an external customer 
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• Process context, including suppliers and inputs, output and customers, 
triggering and resulting events, process controls, enabling resources, and 
performance targets 

• Business transactions detailing the passage of work products between functions 
and roles within an organization and between the organization and suppliers 
and customers 

• State transitions detailing the various stages of work product development as 
they progress and are transformed through the process 

• Business events created both internal and external to the process, and how these 
events trigger the various activities and gateways that make up the process 

• Process decomposition, illustrating how a business process is broken down into 
smaller and smaller units of work from the highest-level identification to the 
lowest-level procedural task 

• Performance expectations detailing the commitment to the customer with 
respect to product or service delivery and the various performance indicators 
established and measured throughout the process to ensure these commitments 
are met 

• Organizational structure and depictions of how the various functions and roles 
within an organization are assembled to support process execution 

• Information system functionality and how that functionality is leveraged to 
support process execution. 

The key takeaway is that comprehensive management of an end-to-end business 
process requires a comprehensive understanding of the business process. This 
understanding must extend well beyond How work is done: it must also address 
What work is done, When, Where, Why, and by Whom. A Business Process 
Management discipline must accommodate the means by which this comprehensive 
understanding is facilitated. 

2.2.6 The means by which business processes are defined and 
represented should be Fit for Purpose and Fit for Use 

Clearly, the development and maintenance of a business process definition that can 
answer every conceivable question about Who, What, Where, When, Why, and How 
work is done for every potential role within an organization would require a 
significant investment in time and resources. If possible at all, the cost of developing 
and maintaining such a model would likely far exceed the value derived from this 
effort. 

While every representation described in the section above is generically valid, it is 
incumbent upon the person(s) responsible for developing and maintaining the 
process definition to understand which representations are required to meet 
business need. In other words, it is prudent to understand what purpose the process 
definition will serve, and focus on building and maintaining only the representations 
that support this purpose. 
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For example, consider the following business needs a process definition might 
support and the different mix of process representations required to support each 
need: 

• The Executive Leadership team relies upon business process definitions to 
support value chain analysis, culminating in the establishment of new and 
modified strategic objectives. 

• The Business Continuity and Disaster Recovery team relies upon business 
process definitions to understand the critical capabilities, processes and 
underlying functions that must be restored to maintain commercial viability 
after a catastrophic event. 

• The Corporate Compliance team relies upon business process definitions to 
ensure the organization is in compliance with external regulations and to 
understand what specific processes and procedures would need to be examined 
in the event of regulation change. 

• The Chief Technology Officer relies upon business process definitions to support 
the development and maintenance of the enterprise technology roadmap. 

• A Functional Manager relies upon business process definitions to ensure 
complete coverage of onboarding, training, and job support material for her 
operations staff. 

• A Business Analysis team relies upon business process definitions to identify 
instances where technology investment will provide a positive return on 
investment. 

• An Information Technology Development team relies upon business process 
definition to understand how information systems requirements and design 
support business function. 

• A Workflow Application relies upon a business process definition to 
automatically orchestrate activities across operations staff and other functional 
applications in a production environment. 

While each of the above business needs is supported by the existence of business 
process definitions, in each circumstance, the information needs and most suitable 
representations of this information are different. The key takeaway is that a process 
definition should be fit for purpose and fit for use: 

• Fit for purpose implies that the process definition contains all necessary 
information to answer the Who, What, Where, When, Why, and How questions it 
is intended to address. 

• Fit for use implies that the process definition is structured to represent this 
information in the most efficient and effective manner possible, considering the 
needs of the intended audience. 
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2.2.7 Business Processes should be managed in a closed-loop cycle to 
maintain process integrity and enable continuous improvement 


Organizations with mature BPM capabilities manage their processes in a closed-loop 
cycle that addresses the planning, design, implementation, execution, measurement, 
control, and continuous improvement of business processes. 


BPM literature is rife with Business Process Lifecycles that describe this closed-loop 
management approach. Regardless of the number of phases in a Business Process 
Lifecycle and regardless of the labels used to describe them, the vast majority can be 
mapped to the Plan, Do, Check, Act (PDCA) Cycle made popular by Dr. W. Edwards 
Deming in the 1950s. 



Figure 9. Deming's Plan Do Check Act (PDCA) Cycle 


Because of its simplicity, celebrity, and lack of bias toward any specific and 
commercialized methodology or framework, the PDCA Lifecycle will be used here in 
our discussion of Business Process Lifecycle and Lifecycle Management. 

Practical application of a Business Process Lifecycle can vary greatly, depending on 
the scope of that to which it is applied. On one end of the spectrum, the Lifecycle can 
be applied separately to Business Processes that are defined, implemented, and 
managed independently of one another. This practice is often seen in one-off 
process improvement initiatives and within organizations whose business and 
process architecture disciplines (and consequently, concepts of architectural 
component interoperability and reuse) have not fully matured. On the other end of 
the spectrum, the Lifecycle can be applied to Business Processes in aggregate when 
it is recognized that the engineering, deployment, and managed coordination of 
many business processes spanning multiple functional organizations is what 
ultimately leads to optimized delivery of value to Customer. This level of Lifecycle 
application is common in organizations that have successfully invested in an 
enterprise-level Business Process Management implementation with a fully baked 
business and business process architecture discipline. 

For this discussion, the PDCA Business Process Lifecycle is applied to a single 
Business Process, as is common in one-off process development or improvement 
efforts. 
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The Plan Phase 

The purpose of the "Plan" phase of the 
PDCA Lifecycle is to ensure that both 
business process context and internal 
process design align with the organization’s 
strategic objectives. 



Defining the business context (Business Context Definition) is the vehicle for 
ensuring a solid understanding of how the process relates to its external 
environment. This critical step is performed to ensure an understanding of process 
scope when the following information, at a minimum, is known: 

• The customer of the process 

• The process output and a clear understanding of why the process output is 
considered valuable to the customer 

• How the process and process output align to the organizational mission and 
support strategic objectives (i.e., how, contextually, the process fits into an 
overarching process architecture) 

• The process input(s), the event(s) that can trigger process execution, and the 
channels through which those triggers can occur 

• The existence of controls, such as external regulation or internal policies and 
rules, which constrain process design and execution 

• Baseline performance (effectiveness and efficiency) targets (assuming this is an 
existing business process) 

• Future-state performance (effectiveness and efficiency) targets 

Once Business Context is established, the internal workings of the business process 
can be designed. This step is critical in defining what deliverables are produced, 
what work is performed, when the work is performed, where, by whom, and under 
what constraints. A well-designed business process will yield and clearly articulate, 
at a minimum, 

• The activities that make up the business process 

• The various deliverables and artifacts that are produced during process 
execution and the various states through which they progress 

• Organizations, functions, and roles that take part in process execution 

• Information systems used to support process execution 

• The various locations in which activities are performed and in which 
deliverables and artifacts related to the process are stored 

• Specific events that drive process execution 
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• Business rules that constrain process execution 

• Process performance metrics and measurement points. 

Additionally, a well-designed business process will detail the relationships between 
the business process components identified above. For example, 

• Which roles are responsible for executing which activities 

• Which activities produce which deliverables 

• Which events trigger which activities 

• Which activities are executed in which locations 

• Which deliverables are stored in which locations 

• Which information systems support which activities. 

Success in the "Plan" phase yields 

• A clear understanding of how the business process supports the Organizational 
Mission. In other words, validation that the process output either indirectly or 
directly contributes to the customer value proposition. 

• Assurance that process design supports the Organizational Vision. In other 
words, if deployed as designed, the process will meet performance expectations 
that can be traced to overarching organizational efficiency and effectiveness 
targets. 

In organizations that lack the ability to engage in proper planning, process 
development is driven instead by assumption and gut feel. These organizations 
often suffer from misalignment, political infighting, operational firefighting, value 
chains broken across functional silos, operational staff feeling disconnected from 
management, and an inability to drive forward progress. 


The Do Phase 

The purpose of the "Do” phase of the PDCA 
Lifecycle is to deploy the process per the 
specifications developed in the "Plan" phase 
and to commit the process to operations. 



Figure 11. 


The physical implementation of business process can take many forms, including 
but not limited to: 
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• Creation of new roles and role responsibilities or the modification of existing 
ones 

• Development or restructuring of functional organizations 

• Build or enhancement of information systems, including functional applications 
and business process and workflow automation 

• Development and deployment of operational support tools such as Standard 
Operating Procedures, Job Aids, and System User Guides 

• Introduction of new customer channels and touch points 

• Creation and implementation of process performance monitoring mechanisms, 
performance dashboards, and escalation mechanisms. 

Once the business process is deployed into operations, the "Do” phase of the PDCA 

Lifecycle also addresses actual process execution. In other words, 

• The process is triggered by initiating events 

• Process inputs arrive 

• Activities are executed 

• Sub-deliverables are produced 

• Process outputs are generated and delivered. 


The Check Phase 

The purpose of the "Check" phase of the 
PDCA Lifecycle is to measure process 
performance against performance 
expectations. 



Figure 12. 


As defined above and illustrated in the diagram below (Figure 13), a business 
process is a collection of activities that produces a specific output of value (product 
or service) to a customer. This definition has both an internal aspect (collection of 
activities) and an external aspect (value to customer), so process performance is 
best monitored from both perspectives. 

Performance measures gathered from outside in, or from the customer perspective, 
are typically referred to as effectiveness measures and are designed to answer the 
question "Are we doing the right things?" These measures are put in place to ensure 
customer needs and expectations are consistently met. 

Performance measures gathered from inside out, or from the internal operations 
perspective, are typically referred to as efficiency measures and are designed to 
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answer the question "Are we doing things right?" These measures are put in place to 
monitor process performance with respect to time and cost. 
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Figure 13. 


A well-architected process definition in the "Plan” phase is the key to achieving 
useful metrics in the "Check" phase. As illustrated in the diagram below (Figure 14), 
customer expectations around product or service delivery drive process 
performance targets. These highest-level performance targets are in turn 
decomposed into underlying performance targets that can be set at the functional 
and operational level. In theory: 

• If all operational targets are met then functional targets are satisfied 

• If all functional targets are met then highest level process performance targets 
are satisfied 

• If all process performance targets are satisfied then so is the customer. 
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Figure 14. 

The "Check" Phase of the PDCA Lifecycle represents the mechanism for measuring 
against these targets. 

A critical factor in understanding the "Check" phase of the PDCA Lifecycle is that 
process performance measurement can be extremely comprehensive, involving the 
gathering of a wide variety of data from a number of sources and feeding a range of 
decisions and actions in the "Do” phase which span a real-time, near-term, and 
longer-term time horizon. 

Traditional categories of performance measures include: 

• Timeliness: e.g., throughput, cycle time and delivery on date promised 

• Product Quality: e.g., freedom from defects, volume of rework and product 
reliability 

• Service Quality: e.g., responsiveness, trustworthiness and service reliability 

• Cost: e.g., labor cost, material cost, overhead and cost of rework 

• Customer Satisfaction: e.g., product or service perceptions meet expectations. 


The Act Phase 

The purpose of the "Act” phase of the PDCA 
Lifecycle is to make determinations and 
react accordingly to process performance 
data collected in the "Check" phase. This 
phase enables maintenance of process 
integrity despite environmental instability 
and through environmental change, and 
ensures the process can be continually 
improved to meet new performance goals 
over time. 



Figure 15. 


Two categories exist for "Acting" on process performance data collected from the 
"Check" phase: 
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• Actions on individual process instances (real-time or near-real-time 
intervention) 

• Identification and planning of change to process definition and deployment (i.e., 
changing the way all process instances will be executed in the future). 

The first category (actions on individual process instances) can only happen where 
real-time or near-real-time performance monitoring exists. For example, as part of a 
new hire process, a workspace must be set up by Space Management two days prior 
to start date. Process monitoring is performed to ensure this occurs. If it does not, 
the issue is escalated along a defined escalation path for resolution. 

The second category (identification and planning of change to process definition and 
deployment) is the feedback loop, which ensures the continuity of a process through 
environmental change and enables the continuous improvement of a process over 
time. For example, from monitoring activities in the check phase, the following is 
determined about the new hire process: 

• 45% of all workspace setups are not completed within the two-days-prior-to 
start-date time requirement and must be escalated, which increases the cost to 
fulfill by $2000 per incident 

• 95% of Human Resource Specialists indicate "Dissatisfied” or "Extremely 
Dissatisfied" with technologies to support pre-employment screening and 
tracking activities 

• A new union requirement dictates that all newly hired full-time employees must 
be provided an ergonomic assessment of their workspace and reasonable 
accommodation within one month of start date 

• Executive leadership establishes a new objective: Reduce time to fill a vacant 
position by 22 business days. 

All of the above examples represent potential changes to the current-state process 
definition and deployment. The "data" to support these observations is collected 
during the "Check" phase of the PDCA Lifecycle. Future-state process definition 
stemming from these observations will occur in the "Plan" phase. Therefore, the 
"Act" phase must accommodate: 

• The collection and aggregation of data and observations from the "Check" phase 

• An analysis of this data and list of observations for criticality and impact 

• The development of recommendations to address the each item in the list (i.e., 
future-state design requirements) 

• A ranking and prioritization of all future-state design requirements to be 
accommodated during the next "Plan" phase of the PDCA Lifecycle. 

2.2.8 Coordinated and Proactive Management of Business Processes 
requires significant investment in internal business capability development 

In our discussion above, the PDCA Lifecycle was applied to the management of a 
single business process in isolation. In reality, on an enterprise-wide or even on an 
organization-wide level, value to customer cannot be wholly delivered through the 
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execution of a single business process, but rather through the coordinated 
management of many intertwined business processes. 

For this discussion, business processes can be categorized into three types: 

1. Primary Processes are end-to-end, typically cross-functional processes that 
directly deliver value to customer. Primary processes are often referred to as 
"core” processes because they represent the essential activities an 
organization performs to fulfill its mission. These processes make up the value 
chain where each step adds value to the preceding step, measured by its 
contribution to the creation or delivery of a product or service and ultimately 
delivering value to a customer. 

2. Support Processes are designed to support primary processes, often by 
managing resources and/or infrastructure required by primary processes. The 
main difference between primary and support processes is that support 
processes do not directly deliver value to customers, while primary processes 
do. Common examples of support processes include those found in information 
technology, facilities, finance and human resource management. While support 
processes are often tightly associated with functional areas (for example a 
process that grants and revokes network access), support processes can and 
often do cross functional boundaries. 

3. Management Processes are designed to measure, monitor, and control 
business activities. They ensure that primary and support processes are 
designed and executed in a manner that meets operational, financial, 
regulatory, and legal goals. Management processes, like support processes, do 
not directly add value to customers but are necessary to ensure the 
organization operates according to effectiveness and efficiency targets. 

As explained earlier in this chapter, the Business Process Management 
discipline, if implemented successfully and comprehensively, constitutes a set 
of internal business capabilities that include the ability to design, deploy, 
monitor, control, and continuously improve business processes. These 
capabilities are themselves realized through the execution of business 
processes that exist solely for the purpose of designing, deploying, monitoring, 
controlling, and continuously improving other primary and support business 
processes. These constitute a Business Process Management Discipline and are 
prime examples of Management Processes. 

Understanding how these three different types of business processes (Primary, 
Support, and Management) interact and interface with each other in a complex 
organization is absolutely essential to understanding the Business Process 
Management discipline. Consider, for example, a car dealership and the total value 
delivered to car dealership customers. This might include: 

• The ability to purchase a car 

• The ability to finance a car (if necessary) 

• The ability to have a car serviced (if elected). 
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From an outside-in 1 perspective, all the customer really sees is the output of three 
business processes: 

• Sell a car (the customer drives off in a new set of wheels) 

• Finance a car sale (the customer receives a payment coupon in the mail) 

• Service a car (the customer brings the car in periodically for an oil change and 
tune-up) 

These are examples of Primary Business Processes because they directly deliver 
value to a customer. 

A look inside the car dealership at what it takes to deliver this value to customer 
reveals a much more complex picture. To deliver this value consistently and to 
remain competitive in the marketplace, the car dealership must possess a number of 
internal capabilities perhaps not recognizable to the customer. For example, the 
ability to 

• Access capital to purchase inventory from manufacturer 

• Assess the marketplace to optimize the mix of used and new cars and car models 
in inventory 

• Order cars from manufacturers and wholesalers 

• Keep the showroom floor and inventory of vehicles clean and presentable 

• Manage customer and supplier data 

• Hire and onboard sales people, finance specialists, and service technicians 

• Manage payroll and benefits 

• Monitor interest rates and assess finance packages and options from competing 
suppliers 

• Stock the service center with parts and tools. 

Each of these "abilities” is realized through the execution of one or more Support 
Business Processes. None of them directly adds value to car dealership customers, 
but a failure in any one of them could result in degradation of value delivered. 

Additionally, if the dealership is truly practicing comprehensive management of 
business processes, it must also possess the ability to do things like 

• Measure customer satisfaction 

• Measure efficiency (time and cost) of service delivery 

• Identify opportunities for process change and improvement 

• Align process improvement opportunities to strategic objectives and prioritize 
them accordingly 

• Build process improvement opportunities into future-state design and deploy 
these designs effectively and efficiently into operations 

• Measure the return on investment of all the above. 


1 Business Process Management (BPM) is a Team Sport: Play it to Win!, Andrew Spanyi, 2003 
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Each of these "abilities” is realized through the execution of one or more 
Management Business Processes that constitute a Business Process Management 
discipline. Like the Support Business Processes, none of them directly add value to 
car dealership customers, but they are put in place to optimize the efficiency and 
effectiveness of this value delivery. 

In enterprise-wide or even in large organization-wide Business Process 
Management implementations where dozens to hundreds or thousands of 
intertwined business processes must be managed in concert, it is typical to see 
investment in the development of specialized capabilities to support this effort. In 
our discussion of Business Process Lifecycle Management, the PDCA Lifecycle was 
applied to the management of a single business process. To apply it to the 
comprehensive management of all Primary, Support, and Management processes 
deployed within an enterprise requires understanding the various specialized 
capabilities that must exist. These capabilities may be housed within a single 
business function (i.e., a "Center of Excellence”) or spread through specialized roles 
across several business functions. 

Managing business processes in aggregate through the "Plan" Phase of the PDCA 
Lifecycle usually involves the development of capabilities to support Process 
Planning and Definition. For example, 

• Strategic Planning to ensure strategic objectives are aligned to market need and 
resulting strategies are tied to underlying capabilities, processes, functions, and 
technologies 

• Enterprise Architecture (incorporating at the very least Business, Information, 
Application, and Technology Architecture disciplines) to ensure that critical 
organizational components are identified and relationships between 
components are optimized 

• Transformation Planning to drive organizational strategies through architecture, 
culminating in optimal and achievable Future-State Operating Models and the 
Roadmaps for achieving them. 

Managing business processes in aggregate through the "Do” Phase of the PDCA 
Lifecycle usually involves the development of capabilities to support Detailed 
Process Design, Build, and Deployment. For example, 

• Portfolio Management to sequence, initiate, and manage the execution of large 
portfolios of business-centric and technology-centric initiatives driven from 
Transformation Planning 

• Project Management to manage individual business-centric and technology- 
centric initiatives underneath project portfolios 

• Organizational Change Management to both prepare for and support the 
organization through change, and to continuously monitor and assess an 
organization’s capacity for change. 
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Managing business processes in aggregate through the "Check" Phase of the PDCA 
Lifecycle usually involves the development of capabilities to support Performance 
Monitoring and Reporting. For example, 

• Performance Monitoring to assess real-time and near-real-time process 
performance and its impact on delivery of value to customer, and also to collect 
data to support future business change and continuous improvement initiatives 

• Performance Reporting to ensure that appropriate process performance- and 
decision-support information is available at the right time and at the right level 
of detail to roles at all levels of the organization, from executives to operations 
staff. 

Managing business processes in aggregate through the "Act" Phase of the PDCA 
Lifecycle usually involves the development of capabilities to support Response to 
Change and Continuous Improvement. For example, 

• Business Process Analysis to assess whether process performance and 
ultimate delivery of value to customer is truly meeting performance 
expectations, and where potential problems or opportunities for 
improvement might exist 

• Change Response and Continuous Improvement to intake, assess, prioritize, 
and act upon both short-term and long-term performance breaches and 
opportunities for process improvement. 

2.2.9 Internal capabilities required to support enterprise-wide Business 
Process Management are developed along a Process Maturity Curve. 

As introduced above, myriad internal business capabilities must be matured to fully 
support a large-scale Business Process Management implementation. Many 
organizations launching into Business Process Management find that these 
capabilities already exist in various states of maturity within the enterprise. In this 
circumstance, moving forward with Business Process Management implementation 
is an exercise in tying together these already-existent capabilities under a process- 
oriented organizational focus and mindset. 

Other organizations in which these capabilities do not exist, especially those that 
commit to Business Process Management because they are in such a state of decay 
and chaos that they must do so in order to remain commercially viable, are faced 
with the daunting task of figuring out how and when to introduce these capabilities 
into the organization. Understanding and tracking the organization’s relative 
placement on a Process Maturity Curve, and also understanding which capabilities 
need to be matured over time as the organization progresses along the Maturity 
Curve, are considered helpful and worthwhile exercises by many organizations in 
the implementation of Business Process Management. 

As with Business Process Lifecycles, BPM literature has an abundance of Business 
Process Maturity Curves, ranging from the very simple to the very complex. A very 
simple maturity curve is presented here to facilitate understanding of the way many 
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organizations sequence the development of internal business capabilities to support 
the maturation of the Business Process Management discipline. 



Ad-Hoc 

Low Process Maturity High 


Figure 16. 

By analyzing the state of its business processes within the context of the Process 
Maturity Curve above (Figure 16), an organization can determine whether the state 
of its processes (either individually or in aggregate) is Ad Hoc, Defined, Controlled, 
Architected or Proactively Managed, and determine accordingly where to focus 
resources in developing internal business capabilities. 

Business Processes in the Ad-Hoc State 

Organizations in the Ad-Hoc state have very little if any understanding and 
definition of end-to-end, cross-functional business process and little visibility into 
the true means by which value is delivered to customer. While pockets of functional 
activity definition may exist (e.g., via existence of Standard Operating Procedure or 
embedded in onboarding and training material), these pockets are typically found 
within disparate functional units; the method of representation is inconsistent and 
often can’t be understood without deep domain knowledge, and the functional 
activity definition rarely ties in a meaningful way to overarching business process. 
Table 2 below summarizes the problems often perceived by organizations with a 
low (Ad-Hoc) state of Process Maturity and many of the primary drivers that compel 
organizations to invest in Business Process Management, with the myriad internal 
capabilities required to support it. 
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Customers / 
Suppliers / 
Partners 

Low customer satisfaction with products or services and 
loss of customers 

Increased penalties for product quality issues and/or 
service breaches 

Unmanageable complexity due to increased numbers of 
customers / suppliers / partners 

Long lead times to meet requests and persistent delivery 
failures 

Supplier and partner complaints, price increases or 
refusal to do business 

Management 

Lack of reliable or conflicting management information 
Lack of visibility into operations to understand and 
predict problems 

Lack of decision-support infrastructure to react 

appropriately when problems occur 

Difficulty attracting and retaining talent 

High cost of onboarding and training staff 

Inability to expand capacity, despite increased headcount 

Massive disruptions stemming from organizational 

change such as reorganization and information system 

deployments 

Employees 

Lack of employee empowerment and satisfaction 
Employee apathy, lack of engagement, and lack of 
accountability 

Employee perception of not knowing what value they 
provide and what is expected 

Employees having difficulty keeping up with continual 
change and growing complexity 

Process 

Unclear roles and responsibilities from a process 
perspective 

Poor product and/or service quality and substantial 
volume of rework 

Large numbers of hand-offs between roles and lack of 
standard protocol between handoffs 
High volume of time addressing, discussing and debating 
exceptions and error handling 

Gross variations in the way work is done by people in the 
same role who are responsible for producing the same 
outcome 

A culture of heroics and a reward system that praises 
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heroes and minimizes the importance of team 
collaborators 

Lack of end-to-end understanding of the process and lack 
of understanding the downstream impact of variations in 
upstream activities 

Roles and functions that make process-related decisions 
with little or no regard for the customer perspective and 
impact on customer 

Information 

Technology 

Perception that IT is disconnected from the business and 
does not understand its needs 

Technology projects that fail to deliver expected value 
Soaring IT costs and a lack of understanding why 
Disproportionate amount of time needed by IT project 
teams to gain an understanding of the business domain, 
business context of the project, and the business 
requirements 

Projects that are thrown over the wall to IT with few or 
unclear business requirements 
IT projects that are thrown back over the wall to the 
business with very little focus on business readiness and 
organizational change management 
A high proportion of IT solutions that are delivered to the 
business but are not fully adopted or are summarily 
rejected 


Table 2. 


Moving from an Ad-Hoc to a Defined state of Process Maturity 
Organization-driving progression from an Ad-Hoc to a Defined state of process 
maturity will often make investments in those capabilities supporting Process 
Planning and Definition and Detailed Process Design, Build, and Deployment. 

Within Process Planning and Definition (the "Plan" phase of the Process Lifecycle) 
it is common to see 

• An increased awareness and understanding of what business process is, how 
it relates to the delivery of value to customer, and how it ties to operations- 
level procedure 

• An increased awareness of how business process improvement initiatives, 
along with technology improvement initiatives tied directly and visibly to 
facilitate business process improvement, support the organization’s strategic 
direction 

• An increased understanding of how organizational structure and information 
technology support business process execution, and therefore the 
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development of better-quality business requirements to drive organization 
and technology changes 

• The emergence of Business Architect, Business Analyst, and Process Analyst 
roles as distinct from technology-focused Systems Analyst roles 

• Investment in the development of a standard and repeatable business and 
business process analysis methodology and toolset 

• A progression from rudimentary two-dimensional drawing and 
documentation tools toward the use of more sophisticated, multi- 
dimensional enterprise architecture and business process modeling tools. 

Within Detailed Process Design, Build, and Deployment (the "Do" phase of the 
Process Lifecycle) it is common to see 

• The development and maturity of project portfolio management and a 
resulting decrease in initiative redundancies, overlaps, and project-team 
collisions (i.e. multiple disjointed project teams driving competing changes 
within the same business process and/or business domain) 

• An improved connection between business and information technology. 
Specifically, an evolution from myopic focus on software development that 
appears disjointed from sound business requirements, toward an expanded 
understanding of business-systems development that may or may not be 
supported by software development 

• Technology deployment efforts that are more tightly coupled with business 
stakeholders and better deliver on business need; an evolution that places 
more emphasis on business readiness, organizational change management, 
and development of business process and procedure definition throughout, 
in conjunction with the Software Development Lifecycle rather than as an 
afterthought, as is common with may technology-driven efforts 

• Organizational focus on the development and deployment of business 
process and procedure for the sake of business process stability and 
repeatability, leveraging a more structured (architecture-driven) framework 
and method for doing so. 

As indicated in Table 2 above, organizations that fail to invest in business process 
definition capabilities suffer from an inability to 

• Keep promises to customers regarding product and service delivery 

• Communicate performance expectations to operational staff 

• Promote an understanding of what constitutes "in compliance” and operate 
within it 

• Achieve consistency and repeatability in process execution 

• Control operational costs, especially in light of increased organizational and 
environmental complexity. 
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Moving from a Defined to a Controlled state of Process Maturity 
Organizations driving progression from a Defined to a Controlled state of Process 
Maturity have truly begun to recognize business processes as assets and have 
discovered that the care and maintenance of them is typically worth the investment. 
These organizations have seen the value of reaching the Defined state, at least in 
localized instances within the organization, and want to protect the investment. By 
analogy, this is similar to the recognition that regular oil changes and servicing on a 
new vehicle are what keep it out of the repair shop and running reliably. 

An organizational commitment to progressing from the Defined to Controlled state 
of Process Maturity requires an investment in those capabilities supporting 
Performance Monitoring and Reporting and Response to Change and 
Continuous Improvement (the "Check" and "Act" phases of the Process Lifecycle). 
Specifically, it is common to see 

• An increased awareness and understanding of what Process Performance 
Management is and why it is important 

• Investment in the tools and techniques to establish effectiveness and 
efficiency targets across end-to-end business processes and an 
organizational commitment to measure and report on them consistently and 
regularly 

• Increased visibility across multiple organizational dimensions through the 
measure and reporting of process performance data. For example, enhanced 
executive management visibility into daily operations, better operations staff 
understanding of management intent and direction, a better understanding 
of end-to-end, cross-functional process execution and its relation to the 
delivery of value to customer, and a better understanding of customer needs 
and expectations 

• The emergence of specialized roles such as Process Owners and Process 
Stewards. These roles are engaged in the management of end-to-end process 
execution across functional organizations and are held accountable for the 
ultimate delivery of value to customer through clearly defined product- and 
service-delivery targets 

• The development of formal internal mechanisms to analyze process 
performance data, intake suggestions for process change, assess unplanned 
changes in the environment, and to aggregate this information into response 
and improvement strategies 

• The development of formal internal structures and methods to facilitate 
cross-functional collaboration and to standardize protocols for cross- 
functional communication and dispute resolution. 

Organizations that fail to invest in business process control capabilities suffer from 

• The inability to definitively prove (i.e. through data) whether investment in 
business process maturation has produced any real results toward the 
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bottom line. Without the ability to prove return on investment, funding 
quickly disappears and the organization is left to assume that the focus on 
business processes is "not what is needed to move forward” 

• The unfortunate (but very common) phenomenon in which significant 

investment is made toward business process definition and deployment, but 
the artifacts become stale as quickly as they are developed because there is 
no mechanism to keep them up to date through business and environmental 
change. Here, too, it is common for organizations to reach the conclusion that 
they "tried that business process management thing and it didn’t work out." 

For these reasons, organizations investing heavily in the "Defined" state of process 
maturity are often advised by consultants and practitioners to invest in the 
development of "Control" capabilities simultaneously. Because of the incredible 
change-management challenges often encountered, especially in organizations that 
are extremely fractured across functional siloes, starting small and in a non-critical 
area of the business is often the chosen strategy. 

Moving from a Controlled to an Architected state of Process Maturity 
As suggested above, organizations that invest in Business Process Management 
implementations are well advised to start small, on narrowly focused pilot projects 
in areas of the business that are not mission critical. This advice has become widely 
acknowledged amongst Business Process Management professionals and 
practitioners and is evidenced throughout Business Process Management literature. 
As Business Process Management concepts and best practices begin to take hold 
within the organization, and as successes are realized, the footprint of Business 
Process Management implementation will begin to grow and expand across the 
enterprise. 

Organizations that experience success in Business Process Management 
implementation and begin to expand the footprint of implementation must address 
the reality that large-scale practice of Business Process Management is incredibly 
information- and data-intensive. Developing a true understanding of and ability to 
manage the "What," "When," "Where," "Why," "How" and "Who" of large Business 
Processes portfolios cannot be done without a dedication to information- and 
knowledge-management and an investment in Architecture. 

A progression from the Controlled to the Architected state of Process Maturity, 
therefore, is a natural and mandatory one as the footprint of Business Process 
Management implementation expands and the volume of business processes 
defined and brought under control increases. 

The concept of architecture and the value it provides to the business is often 
misunderstood. Simply defined, architecture is the identification and definition of 
components and the relationship between components. For example, with respect 
to houses and other types of buildings, architecture is used to identify and define at 
various levels of detail the foundation, framing, roofing, plumbing, electrical, and 
interior-finish components and how they are assembled. Similarly, with respect to 
the business (and in the context of Business Process Management), architecture is 
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used to identify and define the components that make up the business and the 
relationships between these components — i.e., products and services, capabilities, 
processes, procedures, customers, organizations, roles, work products, locations, 
events, business rules, information systems, goals, performance indicators, and so 
on. 

An organizational commitment to progressing into the Architected state of Process 
Maturity requires an investment in those capabilities supporting Planning and 
Definition (the "Plan" phase of the Process Lifecycle), specifically in the 
development of the various Enterprise Architecture disciplines. For example, it is 
common to see investment in 

• Strategic Planning: a discipline that deals with business motivation and the 
customer value proposition. Specifically, Strategic Planning identifies and 
relates components like vision and mission, objectives and strategies, 
products and services, and internal and external health indicators to 
optimize and improve market position. 

• Business Architecture: a discipline that identifies and relates key business 
components such as products and services, internal capabilities, business 
processes, business functions and roles, performance goals, key performance 
indicators, and information systems. Business Architecture ensures critical 
business components are tied together in a manner that best supports 
business strategy. 

• Information Architecture: a discipline that identifies and relates data and 
information components relevant to customers, partners, suppliers, and 
internal business entities. Information Architecture addresses the content 
and structure of data and information components that are created and 
transformed through the various business processes that make up the 
enterprise. 

• Application Architecture: a discipline that identifies and relates the 
enterprise suite of applications and all sub-components that make up 
individual applications to ensure they are scalable, reliable, available, and 
manageable. Application Architecture ensures that the various functional 
application, workflow automation, and business process management 
systems are optimized to support business process execution. 

• Core Services (Service Oriented) Architecture: a discipline that identifies and 
relates the information and technology components assembled to create core 
business services that are implemented through technology. Specifically, 

Core Services or Service Oriented Architecture ensures that the components 
comprising Web Services, web-based applications, databases, and technology 
infrastructure are optimized to make data available and appropriately 
packaged for use (consumption) by business processes. 

Organizations that invest in Business Process Management but fail to invest in the 
development of capabilities related to Architecture suffer from the inability to 
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• Assess the true impact of change across all of the various components that 
affect the "What," "When," "Where," "Why," "How” and "Who" of business 
process execution and delivery of value to customer. For example, the ability 
to answer questions such as "What are all the business processes and 
operations-level procedures impacted by an external regulation change? 
Reorganization? An information-system deployment?" 

• Efficiently identify and fix problems stemming from unplanned change, 
which impacts process performance and product- and service-delivery 
targets 

• Identify component (both business and technology) interoperability 
requirements and opportunities for reuse, or ability to build these factors 
into initial design in order to increase operational efficiencies and prevent 
costly rework. 

Moving from an Architected to a Proactively Managed state of Process Maturity 

Proactive Business Process Management refers to the ability to predict and plan for 
change in order to take advantage of it or to prevent it from compromising the 
delivery of value to customer. Proactive management of business processes is the 
Holy Grail of Business Process Management. Organizations that consistently practice 
proactive Business Process Management are able to control change at all levels of 
the organization rather than be victims of change. For example, in organizations 
practicing proactive Business Process Management, 

• Reorganizations are driven from strategic planning and architecture as a means 
to optimize how functions are structured to support business process execution 
and the delivery of value to customer. During planning it is understood which 
products, services, processes, procedures, functions, roles, job aids and 
information systems will be impacted by the reorganization. These components 
are all assessed for impact: plans to retrofit and update them are established and 
can be controlled in conjunction with the reorganization, rather than as a post- 
reorganization firefight. 

• The organization can quickly, easily, and appropriately respond to regulation 
changes and other external pressures and threats. For example, by many 
estimates, total costs to impacted organizations of addressing the combined Y2K 
threat and the Sarbanes-Oxley Act in the lead-up to the year 2000 and beyond 
was over a trillion US dollars. Much of this cost was incurred because of 
inadequate means to discover the impact on operations and inefficient means of 
driving the appropriate change into operations. 

Organizations practicing proactive Business Process Management have matured and 
broadly deployed internal business capabilities to support all phases of the Process 
Lifecycle in a closed-loop system of management: 
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• The capabilities supporting Process Definition and Planning (the "Plan" phase of 
the PDCA Lifecycle) ensure that the context and high-level architecture of all 
Primary, Support, and Management processes across the enterprise are 
optimized to meet the organization’s strategic direction. 

• The capabilities supporting Detailed Process, Design, Build, and Deployment (the 
"Do” phase of the PDCA Lifecycle) ensure that all business processes are placed 
in operations according to the specifications developed in the "Plan" phase. 

• The capabilities supporting Performance Monitoring and Reporting (the "Check" 
phase of the PDCA Lifecycle) ensure that process performance is consistently 
and holistically measured against performance expectations established in the 
"Plan" phase and that performance information is readily available and 
consumable by all roles that rely upon it. 

• The capabilities supporting Response to Change and Continuous Improvement 
(the "Act" phase of the PDCA Lifecycle) ensure that the organization can best 
determine, and react appropriately to, information collected in the "Check" 
phase. These capabilities ensure that process integrity is maintained despite 
environmental instability and change, and are the catalyst for continued 
improvement of processes over time. 

• From the "Act" phase of the PDCA Lifecycle, new strategic, functional, and 
operational directives are pushed into the "Plan" phase for definition and 
planning, thereby continuing the cycle of this closed-loop management system. 

2.2.10 A Business Process Management implementation requires the 
introduction of new roles into the organization 

As defined, Business Process Management is a management discipline. It represents 
a body of knowledge that addresses the principles and practices of business 
administration and specifies a code of conduct and methods that direct the 
management of business resources. 
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Inherent in the concept of management and management discipline is the concept of 
governance. Generically defined, governance is a structured approach to decision 
making and the means by which decisions are implemented (or not implemented). 
Applied to business processes, governance implies 

• Structured decision making regarding how an organization functions with 
respect to the delivery of value to customer 

• A structured approach to implementing changes in the way an organization 
functions with respect to the delivery of value to customer. 


The end-to-end and therefore cross-functional nature of managing business 
processes creates a need for specialized roles to support governance. In traditional, 
functionally managed organizations, strategic intent is pushed into business 
functions at a very high level, and structured decision making is constrained within 
organizational boundaries. As a result, and as depicted in the diagram below (Figure 
18), inefficiencies and breakdowns most often occur in the handoffs between 
functional organizations because there exists a management vacuum. Because 
functional managers are measured and evaluated for their performance in 
optimizing their functions, there exists a void in responsibility for optimizing the 
handoffs between functions. 


Functional View of the Organization 


^ ^ 


Functional 
Org 1 


Functional 
Org 2 


Functional 
Org 3 


Functional 
Org 4 










Process breakdown at a handoff between functions 


Figure 18 


To address the issue of process inefficiencies, breakdowns, and communication gaps 
between functions, a Business Process Management implementation typically 
introduces new roles into the organization with responsibilities for managing 
processes end-to-end across functional boundaries. 

Note that the intent of this discussion is to not be prescriptive, but rather to 
introduce concepts and provide a framework for conceptual understanding. The 
labels attached to process-centric roles and the exact role responsibilities associated 
with them will vary from organization to organization. The key takeaway is a 
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conceptual understanding of why these types of roles and role responsibilities exist 
and why they are important. 

Also important to note in this discussion is that a single individual representing a 
single position in the organizational hierarchy can play multiple roles. In this 
context, we will see where it might make sense for one individual to have a role with 
responsibilities in the management of a business function, and another role with 
responsibilities in the management of overarching business processes, which his or 
her function supports. 

While the labels may vary from implementation to implementation, for the purpose 
of this discussion we will look at the roles and role responsibilities of the 

• Process Owner 

• Process Leader 

• Process Steward 

• Process Analyst 

• Process Governor. 

2.2.10.1 Process Owner 

The Process Owner is a centerpiece role in a Business Process Management 
implementation and is assigned overall responsibility for the end-to-end 
management of one or more business processes. Specifically, this means that the 
Process Owner is responsible for ensuring the process meets established 
performance (effectiveness and efficiency) expectations. For example, in Figure 19 
below, a performance target of 100 days' cycle time has been set for a specific 
business process. The Process Owner is responsible for ensuring that the process is 
designed, deployed, monitored, and controlled in a manner that meets this target for 
every process instance. 


A Process Owner is assigned responsibility for 
one or more (end-to-end) business processes 



The Process Owner's primary responsibility is 
to ensure the process performs to 
performance expectations 




Figure 19 
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In order to meet these responsibilities, a process owner typically 

• Engages a team of stakeholders to define business process context and ensure 
alignment with strategic objectives 

• Engages a team of stakeholders and SMEs to ensure business process design 
meets expectations within its defined organizational context 

• Serves as point of contact for process-related questions 

• Ensures understanding of how people and systems are engaged to support 
process execution 

• Plays active stakeholder role in business and technology initiatives that impact 
the process 

• Facilitates business process adoption 

• Monitors and reports process performance data 

• Proposes a corrective course of action if process performance is not as expected 

• Escalates instances of significant process performance breaches requiring 
attention 

• Leads a team to assess, prioritize, and implement requests for process change 

• Collaborates with other Process Owners to ensure alignment. 


With respect to organizational positioning of the Process Owner role, there are 
fundamentally two approaches to implementation, Functionally Aligned and Non- 
Functionally Aligned Process Ownership. 


Functionally Aligned Process 
Ownership 

In the Functionally Aligned 
implementation approach, Process 
Owners report to heads of functional 
organizations. In cases where a business 
process transcends organizational 
boundaries (which they most often do), 
there are two options for the 
responsibilities (and therefore the 
accountability) of Process Ownership: 

A single Process Owner is assigned 
even though some process participants 
report to other functional 
organizations 

The responsibility for process 
ownership is assigned to multiple 
Process Owners 
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There are inherent weaknesses in both of these models. In the first, there is a danger 
that process participants from other functional organizations may not recognize 
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Process Owner authority and scope of management, and similarly that Process 
Owners are less likely to take responsibility for issues stemming from other 
functions. The weakness in the second model is that Process Ownership is shared 
across functions. This is really no different than traditional functional management 
structures and introduces the same host of problems, specifically a lack of clarity 
with respect to management of the handoffs between functions. 

The pros of adopting a functionally aligned Process Ownership approach are that it 
is less threatening to the existing power structure and more familiar to operations 
staff. Therefore, functionally aligned process ownership has much less chance of 
being summarily rejected at introduction by the organization. For these reasons, 
many organizations choose to accept in the short term that this approach is less 
effective, and view functionally-aligned process ownership as a baby-step to the 
more effective — but harder to implement — approach of non-functionally-aligned 
Process Ownership. 

Non-Functionally-Aligned Process Ownership 

In the Non-Functionally Aligned implementation approach, Process Owners report 
directly to the head of the organization (or to an organizational structure directly 
under the head). In this case, Process Owners are peers of the to the heads of 
functional organizations in the organizational hierarchy. 


Head of 
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The pros of this approach are that the 
Process Owner is in an appropriate position 
in the organizational hierarchy to address 
cross-functional handoff issues, and there is 
a clear distinction between the 
responsibilities of a Process Owner and 
those of functional management. 

The con of this approach is that it 
significantly changes the traditional power 
structure within an organization. There is a 
high potential for initial resistance 
(typically from functional managers) 

sometimes requiring extreme intervention from executive leadership to get the 
governance model off the ground. 
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Figure 21 
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2.2.10.2 Process Leader 

The role of the Process Leader is 
played by members of the 
organization's executive leadership 
team and may or may not involve 
representatives of the process 
ownership function. 

In organizations where a Business 
Process Management discipline 



Figure 22 
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exists, the typical responsibilities of the Executive Leadership Team members (e.g., 
developing organizational Vision, Mission, and Core Values and establishing 
strategic direction) remain intact. 

Additional responsibilities associated with the role of Process Leader might include 

• Defining the vision and strategy for Business Process Management and 
sponsoring its implementation 

• Ensuring that process performance objectives are established in alignment with 
strategic direction 

• Confirming that process change recommendations and prioritizations are in 
alignment with strategic intent. 


2.2.10.3 Process Steward 

The role of Process Steward is played by members of the organization's functional 
management — that is, the managers of operations staff who execute activities 
within an end-to-end business process. 


In organizations where a Business Process 
Management discipline exists, typical 
responsibilities of the Functional 
Management Team members include 

• Developing knowledge and expertise 
within the functional discipline 

• Attracting and retaining top talent 
within the functional discipline 

• Structuring and developing functional 
team role descriptions and 
responsibilities 

• Defining and maintaining operational- 
level procedures. 



These traditional Functional Manager 

responsibilities remain intact within organizations where a Business Process 
Management discipline exists. Additional responsibilities associated with the role of 
Process Steward might include 


• Ensuring that operational-level procedure aligns with requirements of 
overarching business processes that the function supports 

• Ensuring that operations staff are aware of expectations with respect to 
supporting overarching business processes (e.g. performance expectations, 
expected quality of the output(s) produced by the function, escalation paths and 
circumstances under which escalation is desired, etc.) 

• Gathering and submitting feedback and suggestions for process improvement to 
the Process Owner 

• Membership on the team (led by Process Owner) which assesses and prioritizes 
process change requests 
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• Sharing information with the process owner regarding functional-level 
performance that is relevant to the overarching business process. 

2.2.10.4 Process Analyst 
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Figure 24 

In small Business Process Management implementations, the Process Analyst can 

have responsibilities across all phases of the Business Process Lifecycle. In larger 

implementations, Process Analysts might specialize in one or two key aspects of the 

discipline. A sampling of typical responsibilities includes 

• End-to-end design of the organization's business processes (under direction of 
Process Owner and with input from functional SMEs) 

• Maintenance of the process model repository 

• Collaboration with Process Owner and Stewards to diagnose problems and 
propose solutions 

• Performing analyses (e.g. performance analysis, impact analysis and process 
simulation) as requested by Process Owner and/or Process Stewards 

• Typically, membership on the team that assesses and prioritizes requests for 
process change 

• Typically, membership on process change implementation teams. 
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2.2.10.5 Process Governor 

The role of the Process Governor is 
critical in driving process maturation 
through standardization in the practice 
and use of BPM methodologies and tools. 
This role is less focused on the content of 
the organization’s processes than on how 
that content is documented and 
managed. 
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Figure 25 


The role of Process Governor can be 

played by the same person who is the Process Owner in small BPM implementations 
and when the Process Owner is functionally neutral. However, in implementations 
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where the Process Owner is functionally aligned, it is usually desirable to have a 
separate role of Process Governor (reporting to the Head of the Organization). 

Typical responsibilities of a Process Governor might include 

• Defining Business Process Management principles, practices, and standards 

• Ensuring that Business Process Management principles, practices, and standards 
are scalable across the current and expected future scope of the Business 
Process Management implementation 

• Providing guidance, mentorship, and training on best practices and standards, 
and enforcing compliance with them. 

2.2.11 Business Process Management is not a prescribed framework, 
methodology, or set of tools 

The business landscape is replete with frameworks, methodologies, and tools that 
can be applied to the definition, design, execution, monitoring, analysis, and control 
of business processes. For example, 

• Enterprise Architecture frameworks and methodologies such as Zachman, 
TOGAF, DODAF, and FEAF are often used to define the organizational context 
of business processes and, specifically, their link to strategic objectives. 

• Frameworks and methodologies such as Rummler-Brache and Lean are often 
used to optimize business process design with respect to activities 
performed, deliverables produced, and the human and information system 
resources employed. 

• Business processes can be deployed and executed by various means, 
including work performed by humans, work performed by machines such as 
drill presses and conveyor belts, and work performed by information 
systems such as functional applications and workflow engines. 

• Various methods and tools can be employed to perform real-time, near-real- 
time, and aggregate business process monitoring. Examples include Activity 
Based Timing, Activity Based Costing, SERVQUAL, and Balanced Scorecard. 

• Similarly, countless approaches exist to aid in business process analysis, 
including Six Sigma, Monte Carlo and Discreet Event Simulation. 

The Business Process Management discipline aids an organization in establishing 
those principles and practices that will enable it to be most efficient and effective in 
the execution of its business processes. While a Business Process Management 
implementation can employ any of the above-mentioned frameworks, 
methodologies, and tools, the exact mix will be different for each organization. For 
example, 

• A mature business architecture function for a large and complex 
multinational company to remain competitive might not make sense for a 
50-person startup. 

• A manufacturing operation can achieve process efficiencies by replacing 
human labor with a material handling system, but a mortgage broker can 
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achieve the same by investing in workflow and business process 
automation systems. 

• A manufacturing operation might invest heavily in the ability to monitor 
the cost of production at the activity and task level (Activity Based 
Costing), but a financial services company might choose to invest in the 
ability to monitor customer perceptions of service quality against 
customer expectations (SERVQUAL). 

• An IT organization with highly detailed process specifications and the 
ability to collect detailed process performance measures might employ 
Six Sigma to drive variation from process execution, but the R&D 
organization might choose a less sophisticated process analysis approach 
because of the dynamic and purposefully unstable nature of its 
environment. 

Business Process Management is a management discipline. It assumes that 
organizational objectives can be achieved through the focused management of 
business processes. Under this assumption, it guides organizations in developing 
principles and practices to manage resources, but it does not prescribe a specific set 
of frameworks, methodologies, or tools. These decisions are left to each individual 
organization and each will employ a different mix. This principle can apply even to 
different functional organizations within the same enterprise. 

2.2.12 Technology plays a supporting role, not a leading role, in a Business 
Process Management implementation 

The past decade has seen incredible advancement in the development of 
sophisticated software applications designed to support the Business Process 
Management discipline. Among these applications are tools to enable 

• Business Process Architecture and the ability to model business processes 
within the context of an overarching Enterprise Architecture 

• Business Process Design, including the ability to effectively communicate design 
to varied stakeholder groups and also promote design into process execution 
engines 

• Business Process Execution and the ability to automate the orchestration of 
activities between humans and information systems engaged in process 
execution 

• Business Process Analysis and the ability to automate analysis practices such as 
Activity Based Timing, Activity Based Costing, and Scenario Based Simulation 

• Business Rules Management and the ability to manage business rules 
independently of the business processes they constrain, thereby promoting 
operational agility and flexibility 

• Web Service Development, Service Oriented Architecture, and the ability to 
readily produce enterprise data required in the execution of business processes 

• Round Trip Feedback and the ability to leverage process-execution 
performance data for analysis, and ultimately to influence future process design 
and implementation. 
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As a management discipline that results in improved business performance, 
Business Process Management is practiced through a set of interconnected 
methodologies that together promote the sound engineering and continuous 
optimization of business processes. People in specialized roles, who may or may not 
employ specialized tools to assist them in their practice, execute business Process 
Management methodologies. 

The key takeaway is that Business Process Management is a management discipline 
practiced by people. While it is entirely possible for BPM practitioners to engage 
BPM methodologies without supporting technologies, investment in BPM 
technologies without an overarching set of methodologies does not make sense. In 
short, 

• Information technologies can be employed to support BPM practitioners in the 
execution of BPM methodologies. 

• The IT function is an enabler of BPM efforts, not a leader. 

• BPM implementation is not an IT project but a coordinated modification of 
business management practices that may be enhanced by technology. 

While the practice of BPM with a sound methodology and no supporting 
technologies can be very successful, a BPM effort leading with technology and no 
methodology is doomed to fail. The decision to invest in technology should be 
driven from strong business requirements and a disciplined approach to 
determining a return on investment. Many organizations will decide to invest in 
BPM technologies to further enhance already-successful BPM implementations. 

Of course, if BPM technologies are employed, IT will play an important role in 
technical assessment, architectural design, physical deployment, and operational 
maintenance of BPM technologies. Still, investment of technology and the role of IT 
should always follow sound business need. 

2.2.13 Implementation of Business Process Management is a Strategic 
Decision and requires strong executive sponsorship. 

As presented thus far, a full scale (enterprise-wide or large organization-wide) 
Business Process Management implementation often requires the introduction and 
development of 

• New disciplines such as Enterprise Architecture, Transformation Planning, 
Portfolio Management, Performance Management, and Process Change 
Management 

• New capabilities that leverage these disciplines, such as the ability to optimize 
business process design in alignment with strategic objectives, deploy business 
processes and process improvements into operations, monitor process 
performance, address performance breaches, respond to environmental change, 
and capitalize on opportunities for process improvement 
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• New business processes, roles, and technologies deployed specifically to engage 
underneath these capabilities in the coordinated end-to-end management of 
process. 

The end-to-end management of large numbers of business processes in aggregate 
and across organizational boundaries introduces a new paradigm. New roles 
focused on the end-to-end management of business processes across functional 
organizations must interact with traditional functionally-based managers under 
new governance structures. These introductions fundamentally change the way 
organizations make decisions and the way in which resources are allocated. 

To effect this type of change in an organization can take years and requires a 
tremendous amount of planning, discipline, and perseverance. For these reasons, 
the decision to implement a full-scale Business Process Management discipline must 
be a strategic decision: it requires a top-to-bottom commitment from the 
organization, from executive leadership which defines and supports the practice of 
BPM, through line and functional managers who must collaborate with process 
owners on the design and execution of business processes, to operations staff who 
must often work in extended and virtual teams to ensure value delivery to the end 
customer. 

It is very common for organizations to attempt a Business Process Management 
implementation from a grassroots operational or functional level, but experience 
has shown that without full organizational commitment, the practice and benefits of 
BPM are unlikely to mature. While individual contributors may develop BPM skills 
in a grassroots model, without supporting leadership, values, beliefs, and culture, 
BPM as a comprehensive management discipline is unlikely to take hold in a 
successful, meaningful way. Strong leadership is perhaps most critical, since it is the 
organization’s leaders who most influence culture, set structures, goals, and 
incentives for the organization, and have the necessary authority to make changes 
that create an environment primed for success. 
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Foreword by Craig Le Clair, VP, Principal Analyst, Forrester Research 

Some very large forces today will push process modeling in new directions. Process 
modeling, for example, must support emerging consumer-technology-driven 
"outside in" design approaches and take a stronger role in communicating to the 
business, in very different ways than before: that is, with less emphasis on process 
maps and more on business services and capabilities. 

In addition, data from the outside world — from social media, sensors, and mobile 
capture, referred to as big data — is now growing at an exponential pace in volume 
and importance. Combined with emerging analytics, it will transform processes and 
the tools that support them. 

Process modeling must also evolve, quickly, to accommodate the growing 
importance of big data and analytics in driving processes and at the same time 
provide innovative ways to reduce the skills gap for process analysts, which grows 
daily. For example, although companies use various approaches to tackle process- 
improvement projects, they often end up with departmental processes that do the 
same thing as before — just better or faster. As a result, there is a need to shift from 
isolated BPM improvement-focused projects to sustainable business transformation 
programs, where — yes — process modeling can help. Within this context, a few 
trends stand out: 

Process modeling will better connect strategy to real-time execution for improved 
responsiveness. For years, BPM held out the promise of "round tripping" — the ability 
to continuously model, design, execute, and improve business processes. 
Unfortunately, most BPM solutions have focused heavily on the execution side of the 
equation, giving minimal attention to the strategic side. Over the next few years, 
process modeling will shift the focus of BPM suites from development and execution 
to a more integrated balance between monitoring and executing process strategy. 

To help create this integrated balance, the next generation of BPM suites will 
connect business architecture — capability models, value streams, and strategy 
maps — with real-time process execution to highlight and recommend 
improvements for critical process performance gaps. 

Model-based design must improve communication with business stakeholders. 
Although most enterprises have some tool to model business processes, business 
stakeholders are limited to using Visio or a simplified modeling tool to define and 
document business processes. At the other extreme, more sophisticated 
organizations deploy business process analysis tools that provide extensive 
firepower for modeling and analyzing business processes. In both scenarios, 
business stakeholders currently rely heavily on technical developers to turn process 
models into executable solutions. Looking forward, model-to-execution 
environments will improve usability and allow business stakeholders to integrate 
with internal applications and services, with minimal support from traditional 
application development teams. 

Process modeling will treat data as a first-class citizen of business processes. Today, 
most business process professionals view data as a given and pay little attention to 
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owning or maintaining data quality. However, in the future, master data’s role will 
become the linchpin to delivering integrated customer experiences across different 
channels, as the disconnect between process and data becomes a thorn in the side of 
business process professionals driving customer transformation initiatives. The 
explosion of big data and analytics will create a new "lighter" form of modeling as 
organizations seek value from a growing number of digital and analog sensors, 
social media, financial systems, emails, surveys, and customer call centers — to name 
a few. New data-centered-tool tidal waves swell on the horizon. These new 
productivity tools will begin to model "metadata" and bypass traditional process 
models. 

Teams will increasingly use collaboration to tap business strategists, customer 
experience experts, process transformation gurus, and technologists. Like the siloed 
processes in organizations, groups working on transformation are often organized 
in small silos and scattered across the enterprise. We routinely see process 
excellence teams working in business operations using Lean and Six Sigma to 
improve or transform processes, while marketing teams work on transforming the 
customer experience and IT professionals are busy putting in BPM suites. Each of 
these groups has much to offer, but their efforts often proceed in isolation. By 2015, 
companies that embrace collaborative process modeling will combine the best of 
these efforts into one strategic initiative, and put experts into centers of excellence 
throughout the organization. These integrated, holistic teams will also include 
business strategists and change-management experts to increase the chance of 
profound, lasting change. 

Business-ready process modeling will abstract configuration from technical 
complexity. Technologies supporting the business, including enterprise apps, 
business process management suites, dynamic case management, collaboration and 
mobile apps, are becoming inherently easier to use and manage. This is driven by 
improvements in end-user interfaces, as well as by configuration improvements that 
present more intuitive (and increasingly graphical) set-up tools that abstract 
technical complexity. As more software vendors deliver business-ready technology, 
business process stakeholders will become less dependent on IT to configure 
processes and unlock new features of the applications. 

This is a great time to be a process specialist, whether you are part of a business 
architecture team in IT or an analyst supporting the business directly. The demand 
for your skills is growing, and the tools to support you will make your efforts more 
rewarding. 
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3.0 Introduction 

Process Modeling requires a critical set of skills and techniques that enable people 
to understand, communicate, measure, and manage the primary components of 
business processes. For enterprises aware of the high value of their business 
processes, process modeling is the foundational activity for managing the 
enterprise. 

3.1 Business Process Modeling 

Business Process Modeling is the set of activities involved in creating 
representations of an existing or proposed business process. It can provide an end- 
to-end perspective or a portion of an organization’s primary, supporting, or 
management processes. 

3.1.1 Use of models 

A model refers to a simplified representation of a thing, concept, or activity. Models 
can be mathematical, graphical, physical, narrative, or a combination of these. 
Models have a wide range of applications in business environments, including 

• Organizing (structuring) 

• Discovery (learning) 

• Forecasting (predicting) 

• Measuring (quantifying) 

• Explaining (teaching, demonstration) 

• Verification (validation) 

• Control (constraints, objectives). 

Business processes can be expressed through modeling at many levels of detail, 
ranging from highly abstract to highly detailed. A fully-developed business process 
model will typically represent several perspectives serving different purposes. 

3. 1.1.1 Process model contents 

A process model includes icons that represent workflow, data flow, events, 
decisions, gateways, and other elements of the process itself. A process model can 
contain illustrations and information about 

• The icons (representing the process elements) used in the illustrations 

• The relationships among the icons 

• The relationships of the icons to their environment 

• How the icons represented behave or perform. 

3. 1.1. 2 Identifying a process model 

When looking at a business "illustration," use the following table to decide whether 
you are looking at a process model or a process diagram or process map. 
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Is it a Model? 

A process model 

A process diagram or process map 

■ 

Standardized notation convention 

■ 

Notation ambiguous 

■ 

As precise as needed 

■ 

Precision lacking 

■ 

More detailed 

■ 

Less detailed 

■ 

Icons are objectively defined and 

■ 

Icons (representing process 


standardized 


components) “made up” or loosely 

■ 

Icon relationships definite and 


defined 


explained in annotations, process 

■ 

Relationships of icons portrayed 


model glossary, and process narratives 


visually 

■ 

Can depict appropriate complexity 

■ 

Limited to portrayal of simple ideas 

■ 

Can grow, evolve, mature 

■ 

One-time “snapshot” 

■ 

Should be created with tool appropriate 

■ 

May be created with simple drawing 


to the project 


tools 

■ 

May provide manual or automated 

■ 

Difficult to use for even the most simple 


process simulation 


manual simulation 

■ 

Vertical and horizontal linking, showing 

■ 

Difficult to link with related products 


relationships among processes and 
different process levels 

■ 

Uses ordinary file management 
structures 

■ 

Uses a repository of related models 
within a BPM system 

■ 

Appropriate for certain quick capture of 
ideas 

■ 

Appropriate for any level of process 
capture, analysis, and design 

■ 

Not suitable for import into a BPMS 

■ 

Can import into a BPMS (business 
process management system) 




Table 3 


3. 1.1. 3 Static vs. Dynamic Models 

Using static models 

Static models represent a single state of a business process or certain elements of a 
business process. Static representations 

• Establish baselines 

• Document configuration stages 

• Depict certain future states based on assumptions of goals or risks of the 
process 

• Manage change 
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• Drive the process toward a more advanced level of maturity. 

3. 1.1.4 Dynamic models 

Models or some elements of a model can be constructed with dynamic features. 
Examples of dynamic models include those that are designed to allow interaction 
with a user or those that show the development of a trend over time. 

3. 1.1. 5 Dynamic modeling tools 

Most top-tier modeling tools provide dynamic interaction capabilities. In some 
cases, the most basic version of a modeling tool will have simulation capabilities 
appropriate for most modeling projects. As a modeling project progresses and 
requires more detailed analysis, you may need more advanced and even automated 
simulation capabilities. If so, consider obtaining the capabilities you need from the 
vendor of the tool you are using, or as an add-on from a partner of the original 
vendor. 

3. 1.1. 6 Combining static and dynamic models 

Often a modeling effort benefits from a mixture of static and dynamic models. For 
example, when considering a future process configuration (the "To-Be" process), by 
feeding sample data through a dynamic process model you can see how the actual 
process will perform. Conversely, cycling of a dynamic model can produce a 
desirable set of static "snapshots" to aid in further analysis. 

3.1.2 Process Components and Tools 

3. 1.2.1 Process modeling tools capture process components 

Process components specify the properties, behavior, purpose, and other elements 
of the business process. You can use some modeling tools to capture and catalogue 
process components and the information associated with each component to 
organize, analyze, and manage an organization’s portfolio (i.e., collection) of 
processes. 

3. 1.2. 2 Modeling tools capabilities 

Modeling tools vary in the number and types of components (and information) they 
can capture, which affects the type and level of process performance analysis you 
can perform. Process modeling projects frequently grow in scope and complexity. 
Because of this, selecting a more powerful tool than required at the beginning of a 
modeling project often makes the most sense. 

Examples of process components 

Table 4 presents some process components (and related information) you can 
capture in process models. 
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Examples of Process Components and Data in Process Models 

Inputs/Outputs 

Arrival Patterns/Distributions 

Events/Results 

Costs (indirect and direct) 

Value Add 

Entry Rules 

Roles / Organizations 

Exit Rules 

Data/Information 

Branching Rules 

Probabilities 

Join Rules 

Queuing 

Work/Handling Time 

Transmission Time 

Batching 

Wait Time 

Servers (number of performers available 
to perform tasks) 


Table 4. Examples of Process Components and Data in Process Models 


3.2 Purpose of Process Modeling 

3.2.1 Task at hand drives process modeling 

As a work activity, the purpose of process modeling is to create a representation of 
the process that describes it accurately and sufficiently for the task at hand. For this 
reason, the level of detail to model and the specific type of model is based on what is 
expected from the modeling project. A simple diagram may suffice for one project, 
while a fully developed model may be required for another. 

3.2.2 Process modeling is a means to business ends 

Process models are the means to 

• Manage organization processes 

• Analyze process performance 

• Define changes. 

Process models can express a target business state or specify the requirements for 
resources to enable effective business operations, such as people, information, 
facilities, automation, finance, and energy. 

The following table outlines, from different points of view, some reasons for process 
modeling. 
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Point of View 

Reasons for Process Modeling 

Business community 

• Save money — cut costs 

• Improve quality — reduce waste 

• Reduce time to production 

• Increase productivity 

• Reduce time for order to delivery — customer satisfaction 

• Target problems to fix those problems 

• Capture performer knowledge — avoid process breakdown 

• Standardize employee performance 

Business process 
professional 

• Solves a business problem by 

Describing the process as accurately and sufficiently as 
necessary for the task at hand 
Communicating the process clearly to the intended 
audience 

Selecting the level of detail and the specific type of 
model depending upon what is expected of the 
modeling project and the business problem that needs 
fixing 

Organizational 

• Process models are the means to 

Manage the organization’s processes 
Analyze process performance 
Define changes 

• Process models can 

Express a target business state 

Specify requirements for resources to enable effective 
operations (e.g., people, information, facilities, 
automation, finance, or energy) 

Analysis and 
performance 
improvement 

• Increase clarity or understanding of a process 

• Aid in training 

• Assess performance against standards and compliance 
requirements 

• Understand process performance under varying loads or other 
changes 

• Analyze potential opportunities for improvement 

• Design a new process or a new approach to existing process 

• Facilitate communication and discussion 

• Document a requirements determination effort 

Process-managed 

business 

• Central starting point to drive collective understanding and 
consensus among process stakeholders 

• Save costs, time and effort over guesswork and experimentation 
with the actual processes 

• Help process performers from a department see how their 
inputs and outputs affect the development of value across 
functional lines 

• May result in local decision making that maximizes value in the 
process rather than producing local optimization 


Table 5. Reasons for Process Modeling 
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3.3 Commonly Used Process Modeling Notations 


A notation is - A standardized set of symbols and rules that 
govern how the symbols represent something else. 


For example, musical notation includes universally recognized symbols for notes 
and clefs. Similarly, a business process modeling notation includes icons (pictures) 
and connectors that help show relationships among the various real-life 
components of a business process. 

There are a number of modeling and notational standards and techniques in use 
today. Selecting the best approach from the available options can be difficult; 
however, selecting an approach that follows standards and well-known conventions 
provides far-reaching advantages, as listed in Table 6. 


Benefits to Using a Standard Modeling Notation 

• Members of the business community, business process professionals, and IT 
professionals have a common symbol set, language, and technique through 
which to communicate. 

• Resulting process models are consistent in form and meaning which 
simplifies design, analysis, and measurement while enabling model re-use. 

• Staff can import and export process models among various tools. 

• With some tools, staff can transform the modeling notation into an execution 
language. 

• There is a significant growth trend in some of these features, notably the 
import facility and compatibility with execution engines. 

Table 6. Benefits to Using a Standard Modeling Notation 

Guidelines for selecting a modeling notation 

This section provides a brief description of some of the most commonly 
encountered modeling notations. Note that the examples provided are just the 
graphical veneer of the notational systems presented. In modern modeling 
environments, there may be many levels and detailed attributes that help to more 
fully describe a business process. 

When choosing a modeling notation, consider the unique combination of 
circumstances in your organization. Review the modeling notations in Table 7 to 
help make the selection. And keep in mind it is sometimes appropriate to use 
different notations for different stages of a modeling project or for different levels or 
types of models. 
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Commonly Used Process Modeling Notations 


Modeling Notation 

Description 

Business Process Model 
and Notation (BPMN) 2.0 

Standard created by the Object Management Group; 103 
icons, useful for presenting a model to multiple 
audiences 

Swim Lanes 

Not a distinct notation, but an addition to most other 
notation systems; helps identify hand-offs in a process 

Flow Charting 

Originally approved as an ANSI standard, includes a 
very simple and small set of symbols that are not 
standardized; facilitates "quick capture” of process flow 

Event Process Chain 
(EPC) 

Developed within the framework of ARIS, considers 
events as triggers to or results from a process step; 
useful for modeling complex sets of processes 

Unified Modeling 
Language (UML) 

Maintained by the Object Management Group, a 
standard set of diagramming techniques, notations 
primarily for describing information systems 
requirements 

Integrated Definition 
Language (IDEF) 

A Federal Information Processing Standard that 
highlights the inputs, outputs, mechanisms, and controls 
of a process, and clearly links processes up and down 
levels of detail; good starting place for an enterprise- 
wide view of an organization 

Value Stream Mapping 

From Lean Manufacturing, a very simple set of symbols; 
used to add process resource costs and time elements to 
a process model to clearly depict process efficiency 


Table 7. Commonly Used Process Modeling Notations 

3.3.1 Business Process Model and Notation (BPMN) 2.0 

Business Process Model and Notation 2.0 is a standard created by the Business 
Process Management Initiative, now merged with the Object Management Group 
(OMG), an information systems standards-setting group. BPMN has growing 
acceptance as a standard from many perspectives, which has resulted in its 
inclusion in several of the most widely used modeling tools. It provides a robust 
symbol set for modeling different aspects of business processes. Like most modern 
notations, the symbols describe definite relationships such as workflow and order of 
precedence. 
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Key features 

• Version 2 (BPMN 2.0) represents significant maturing and solidification of 
the notation 

• Over 100 total icons, organized into descriptive and analytic sets to meet 
different user needs 

• Very precise notation indicating: beginning, intermediate, and end events; 
activities, and message flows; intra-business communications and inter- 
business collaboration; and activity and data flows. 

When to use 

• To present a model of a process to multiple sets of audiences 

• To simulate a business process with a process engine 

• To execute a process. 

Advantages 

• Widespread use and understanding; considered by many to be the de facto 
standard in the U.S. 

• Significant use in the U.S. Department of Defense and other government 
entities 

• One of the most powerful and versatile notations for identifying process 
constraints. 


Disadvantages 

• Requires training and experience to use full set of symbols correctly 

• Difficult to see relationships among multiple levels of a process 

• Different modeling tools may support different sub-sets of the notation 

• Information Technology origins inhibit use with some organizations’ 
members of the business community. 
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Example 



Figure 26. Simple BPMN Process Diagram 


For more information: 

• The Object Management group’s dedicated website at 
http://www.bpmn.org/ 

• Help files and sample models in most major modeling tools. 

3.3.2 Swim Lanes 

Swim lanes are not a distinct notation but rather a useful notational addition to 
most other notation systems. They are often incorporated into BPMN, EPC, UML, or 
simple flowcharting as a means of defining the performer responsible for 
performing an activity. The lanes (rows) are generally represented as long vertical 
or horizontal rectangles or sometimes as simple lines or bars, resembling the 
channel or lane markings in swimming competitions. Arranging the flow of activities 
and tasks across these rows makes it easy to visualize handoffs in the work. 

Key features 

• The lanes represent performers or combinations of performers 

• Lanes could indicate roles, organizations, systems, or any other performer 
entity or combination. 
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When to use 

• To clearly distinguish at what point the responsibility for performance 
changes 

• To increase understanding among process stakeholders. 

Advantages 

• Aids collaboration as process performers are able to distinguish their roles in 
relation to others 

• Clearly defines hand-off points in a process 

• Can describe flows of operational precedence, material, and messages. 
Disadvantages 

• Becomes complex in areas where performance responsibility is jointly held 

• In certain cases, can preserve a silo process mindset. 

Example (used in BPMN) of one "pool" and three lanes 



Figure 27. Traditional swim lane diagram. (Provided by Bruce Silver, with permission from the author.) 


For more information: 

• http://www.agilemodeling.eom/style/activityDiagram.htm#Swimlanes 

• Help files for most major modeling environments 

3.3.3 Flow Charting 

Flow charting is widely used; it is based upon a simple set of symbols for operations, 
decisions, and other primary process elements. The notation for the most common 
flow charting was approved as an ANSI standard in 1970 for representing systems 
flows. Other flow-charting notations have been used by industrial engineers for 
decades and utilize different symbols and layouts for specific industrial mappings. 
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For example, flow charting is used to describe the flow of materials, roles and work, 
or placement of machinery, analysis of egress and ingress in dispatch centers. 

Key features 

• Used with or without swim lanes 

• Many variations for different purposes 

• Simple core set of easily recognized symbols 

• Forerunner of many more modern notations. 

When to use 

• To quickly capture process flow for sharing where details do not require 
documenting 

• To begin a modeling project where funding is not available for full-featured 
tools 

• To develop highly detailed diagrams for use in traditional system coding. 

Advantages 

• Well understood by software engineers and systems engineers 

• At high levels, helps build consensus 

• Adequate for "happy path" illustrations 

• Inexpensive to use 

• Supported by lower-order tools including general-purpose graphics and 
visualization tools. 

Disadvantages 

• Despite influence from ANSI standards, there are many variations 

• May be imprecise when used to depict complex business processes 

• Objects do not have robust set of descriptive attributes 

• Models constructed are "flat," requiring the use of connector symbols to 
show where process segments continue 

• Not generally considered robust enough for complex process capture. 

Examples (showing a few of the most commonly used symbols) 

Two examples are provided below to illustrate how much flow-charting symbols 
can vary in appearance from one organization to another. 
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Figure 28 
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Figure 29 


For more information: 

• Applicable ANSI standards 

• Introductory computer programming course texts 

3.3.4 Event Process Chain (EPC) 

Event Process Chains range from very simple to very complex. EPC describes events 
as either triggering or resulting from a process step, called a "function." Thus, the 
flow is normally event-function-event. EPC relies heavily upon logical operators 
called "rules." The basic rule objects are "AND," "OR," and "Exclusive OR." These rule 
objects express decisions, tests, parallelism, and convergence in the process flow. A 
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simple EPC consists of just these objects plus arrows that define relationships 

between them. 

Key features 

• The EPC method was developed within the framework of ARIS by Prof. 
Wilhelm-August Scheer at the Universitat des Saarlandes in the early 1990s 

• It can be used for modeling, analyzing, and re-designing business processes 

• May be enhanced with vertical or horizontal swim lanes 

• Simple core set of easily-recognized symbols, augmented with a large 
number of optional or special-purpose objects 

• Some tools employ a system of filters to limit or control the subset of the 
notation to be used. 

When to use 

• Modeling complex sets of processes with many process interfaces and sub- 
models 

• To fill in details of processes below the levels normally addressed by some 
enterprise architecture frameworks 

Advantages 

• Widely used and understood in Germany and other European countries, 
especially in multinational enterprises 

• Substantial presence in the U.S. Department of Defense and other large 
enterprises 

• A properly constructed EPC may be read like a set of sentences 

• May be used as a means of collaboration among groups of functional experts 
who have little experience with models 

• Possible to enhance the models through the use of many optional object 
types that describe performers, supporting systems, information, or swim 
lanes of related activity 

• Some tools may translate between EPC and BPMN notations with growing 
reliability 

• One of the most powerful and versatile for identification of process 
constraints. 

Disadvantages 

• Less prevalent than BPMN and Flow Charting in U.S. modeling projects 

• Modeling teams must be disciplined in the use of the notation to avoid 
possible logic gaps 

• Strongest implementation is limited to the ARIS family of process modeling 
tools. 
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Example 
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Figure 30. Event Process Chain (1) 
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Figure 31. Event Process Chain (2) 


For more information: 

• http://www.ariscommunity.com/ 

• http://www.softwareag.com/corporate/products/aris_platform/modeling/ 
defaultasp 

3.3.5 Unified Modeling Language (UML) 

UML provides a standard set of diagramming techniques and notations primarily for 
describing information systems requirements. While UML is primarily used for 
systems analysis and design, a few organizations also use UML activity diagrams for 
business process modeling. UML is maintained by the Object Management Group 
(OMG), a standards-setting body for the information systems field. 

Key features 

• Actually a set of nine or more related diagramming techniques and notations 

• Describes very complex lateral and parent-child relationships 

• Symbol set varies somewhat depending on model type 
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• An important subset, SysML, often used to describe systems and systems of 
systems. 

When to use 

• To develop use cases 

• To describe information systems requirements 

• To design system interactions below the level of the process flows depicted 
in other tools 

• To capture or design data structures 

• May also be used to depict business process flows at a lower level 

• Often used to present 'use' cases. 

Advantages 

• Well-established community of users 

• Implemented in most major modeling environments 

• Many references available from books and online sources. 

Disadvantages 

• Designed for modeling software applications; business process modeling is a 
secondary use 

• Notational representation may vary from tool to tool 


Example 

(See Figure 32 below) 



ram.html 
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For more information: 

• Object Management Group maintains a complete specification for this 
notation at http://www.uml.org as well as links to other useful information 

• Help file structure in IBM Rational software. 

3.3.6 IDEF 

IDEF is a family of modeling notation concepts that are described in a Federal 
Information Processing Standard (FIPS) that was developed by the US Air Force. It is 
a notation and technique that is one part of a methodology for defining the work 
processes and information systems in manufacturing environments. It was widely 
used and available in many modeling tools for many years and is now in the public 
domain. 

The notation employs a very simple set of symbols consisting of process boxes with 
arrows showing inputs, outputs, controls, and mechanisms. Although each level of 
the model is read left to right and top to bottom, the numbering system used for the 
major steps are represented in a way that allows for easy association between 
parent and child levels of decomposition in the process. Thus, a child process box 
named A1.3 is interpreted to be a child process of the parent diagram Al. Each 
successive level of decomposition uses another decimal point to continue this easy 
traceability of lineage. 

Key features 

• Top level defines the topic to be modeled 

• Subsequent levels display decomposition of the level above with a series of 
boxes 

• Steps in the process have inputs, outputs, controls and mechanisms depicted 
by labeled arrows 

• System of labeling indicates exact relationship with next level above (B32 is 
the second process sub-step of the B3 process step). 

When to use 

• May be used for any level of activity modeling 

• Integrated Computer Aided Manufacturing (ICAM). 

Advantages 

• Precise expression 

• Easy-to-follow logical decomposition of model levels 

• Exhaustive documentation available from U.S. Federal government or 
commercial sources. 

Disadvantages 

• Implementations are often visually unappealing 

• Notation consisting mainly of boxes and arrows can appear cluttered and 
busy. 
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Example 
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Figure 33. IDEF Sample Diagram 


For more information 

• Draft Federal Information Processing Standards Publication 183 

• Computer Associates BPWin product description. 

3.3.7 Value Stream Mapping 

Value Stream Mapping is a technique used in Lean Manufacturing. Not to be 
confused with Value Chain notation, Value Stream Mapping expresses the physical 
environment and flow of materials and products in a manufacturing environment. 
At Toyota, where the technique originated, it is known as "Material and Information 
Flow Mapping." Value Stream Mapping is used to add process resource costs and 
time elements to a process model, to incorporate the view of the process efficiency. 

Key features 

• Very simple set of symbols 

• May incorporate diagramming from other notations. 

When to use 

• To increase involvement of process performers in process analysis 

• To help guide performers in self-identifying opportunities to lean a process 

• In any project that does not require the use of full-featured modeling 
environments 

• In environments where process costs and time requirements are easily 
identified. 

Advantages 

• Simple, easy to use 
Disadvantages 

• Flat models 

• No repository 
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• Unable to use for very complex issues 


Example 


(See Figure 34 below) 



Figure 34. Value Stream Mapping Sample Diagram (Reprinted from LSixSigma publication) 


For more information 

• Most Lean and Six Sigma texts 

3.4 Specialized Approaches in Process Modeling 

The following three approaches can be used in process modeling or process 
improvement initiatives. They are considered specialized approaches, each 
providing an enterprise perspective analysis. Further detail and sample materials 
are available from the websites for each approach, listed below. 


Specialized Approaches in Process Modeling 

Modeling Notation 

Description 

Value Chain 

Introduced by Michael Porter, this notation emphasizes 
capturing those processes and activities that "add value" 
to the service or product provided to a customer. 
Provides an overview but not detailed view of business 
processes. 

Supplier, Input, Process, 
Output, and Customer 
(SIPOC) 

A style of process documentation used in Six Sigma, 
useful to emphasize the sources of inputs (suppliers) 
and the targets of the outputs (customer). 

System Dynamics 

Systems Dynamic models present a dynamic view of a 
business system’s performance. 
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Table 8. Specialized Approaches in Process Modeling 


3.4.1 Value Chain 

Value chain notations are a category of symbol sets used to visualize the 
accumulation of value or steps toward achievement of a goal. Various approaches to 
value chains employ their own sets of symbols, but these are generally easily 
interpreted and often employ an arrow or horizontal chevron to express each step 
in the chain. Relationships are also generally easy to understand, with the chief one 
describing a predecessor-successor relationship. 

Sometimes groups of steps are summarized under a "process superior" object. 
These models generally flow from left to right, describing the sub-processes that 
directly contribute to producing value for the organization’s customers (clients or 
constituents). The concept of the value chain was introduced by Michael Porter in 
his works on corporate strategy and is typically applied at the enterprise modeling 
and planning level. 

Key features 

Features vary among tools: 

• Sometimes implemented as Value-Added Chain Diagram 

• Overlays representing performers, finance, time, systems, or specific data 
clusters may be added 

• Swim lanes may be used to enhance effectiveness 
When to use 

• To create a decomposition of those process segments that relate most 
directly to adding customer value 

• To depict overview levels of processes 

Advantages 

• Easy to read and interpret 

• Little ambiguity because of simple relationships 

• May be augmented with optional input and output identification, or other 
overlays such as financial or organizational involvement 

Disadvantages 

• Decision points unclear 

• Usefulness breaks down with increased complexity, requiring use of more 
detailed notations for further decomposition 
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Example 



For more information 

• A Value Chain Reference Model has been proposed by The Value Chain 
Group, Inc. at http://www.value-chain.org/en/rel/19/ 

• A strong Value-Added Chain Diagram implementation is included in 
modeling tools from Software AG (ARIS). 

3.4.2 SIPOC 

SIPOC stands for Supplier, Input, Process, Output, and Customer. It is a style of 
process documentation used in Six Sigma. There is no standard or preferred 
notation set and this technique may be satisfied by completing a table with those 
headings. The SIPOC model is often used to gain an initial consensus on what areas 
of a process are under study. 

Key features 

• Simple columnar arrangement (not swim lanes) 

• Text entries or well-understood notational elements may be used to populate 
the columns 

When to use 

• Used extensively at the onset of Lean and Six Sigma projects 

• The exercise of naming the entities in each column can accelerate detailed 
modeling in another tool 

• Use for initial consensus-building of process modeling project scope. 
Advantages 

• Fast 

• Simple 

• Requires only a template in a spreadsheet or word processing document 
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Disadvantages 

• Little potential for in-depth capture, design, or analysis 

• May delay the adoption of a more powerful method 

Example 

SIPOC Worksheet 

For Process: 


Supplier 

Inputs 

Process 

Outputs 

Customer | 

Record 

entities 

that 

provide the 
inputs that 
trigger the 
process 

Record each 
of the inputs 

Steps to respond to inputs 
(may be a list or simple 
graphics) 

List outputs 

Record the 

entities 

that 

receive the 
result of 
the 

process 


Figure 36. SIPOC Worksheet 


For more information 

• http://www.isixsigma.com 

3.4.3 System Dynamics 

More than just a different notation, System Dynamics models are "activity on arrow" 
diagrams rather than "activity on node" diagrams like most of the other notations. 
System Dynamics models are especially useful in developing dynamic lifecycle-type 
models that focus on the overall business system’s performance and the impact of 
changing the key variables that affect overall performance. These are more often 
used to model an entire enterprise or line of business rather than lower-level 
workflow type models. System Dynamics models are often used to describe the 
enterprise business "architecture" from a dynamic behavioral perspective, rather 
than a static structural perspective. 

Key features 

• Causal and feedback loop diagrams 

• Dynamic — via controlled animation demonstrates how process performs 
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When to use 

• To provide a "macro view," simulating an organization’s overall performance 

• To compare impacts of changing multiple variables on a process or an 
organization. 

Advantages 

• Presents active, moving, fluctuating representation of a high-level process 

• Easier to understand than a static representation or text description. 

Disadvantages 

• Not useful for discerning problems at the worker level or with supporting 
computer applications 

• Not useful for discerning influences external to a process upon that process 

Example 

• The following is only a "snapshot" from a System Dynamics model. An actual 
System Dynamics model is not static, but shows with movement how 
changing variables affect a process. 



Dynamic stock and flow diagram of model New & 
product adoption (model from article by John 
Sterman 2001) 


Figure 37 


For more information 

• System Dynamics Society: http://www.systemdynamics.org/ 
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• System Dynamics — MIT Sloan PhD Program: 

http : / / mitsloan.mit.edu /phd/ system-dynamics.php 

• The System Dynamics Review, the journal of the System Dynamics Society: 
http : / / www.systemdynamics.org/ publications.htm 

3.5 Process Model Levels 

Assigning process information 

Process information discovery uncovers information at various levels of detail. 
These levels of detail need to be sorted out and the information assigned to the 
different levels of processes within a process model hierarchy. The top level of the 
hierarchy shows the end-to-end process. From there it is broken down 
(decomposed) into lower levels of detail until the activities where the "work" of the 
process is performed are identified. 

Aligning process information 

When collecting process information, consider assigning process information to the 
appropriate process level as the information is collected. As the team learns more 
about the process, the process information can be re-assigned. Be sure to align the 
information at any level in the hierarchy to information at a higher level in the 
hierarchy. By doing this, the information at each level provides additional detail to 
the information at the next higher level. Additionally, aligning process information 
across process levels allows the team to identify missing information or information 
that needs to be questioned. 

The diagram below is an example of a process hierarchy, starting at the highest, 
least detailed level, the Enterprise Process level, and "drilling down” to the Business 
Process level and Workflow level. 

Levels vary in number and name 

The number of levels and their names will vary according to the methods and 
naming conventions in different companies. Key points to remember: 

• The process must be broken into a low enough level to understand the 
activities that are taking place and how they fit together to produce the 
business unit’s end products. 

• If there is to be any hope of controlling the process information and its 
quality, the team needs a way to organize the information that is collected 
and the models that are built. 

The levels in the figure below are an example of how a company can look at defining 
levels of detail in their process modeling standards. 

Best practice: business modeling standards 

Formal business modeling standards should direct the number and name of the 
levels in both the current "As Is" and the future "To Be" models. In the past, these 
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standards could be independent of any external modeling standard or tool, but that 
is changing. Consider aligning internal modeling standards with the tools that are 
used and their capabilities and limitations. For example, while it is not the only 
modeling standard, BPMN 2.0 is becoming a major standard for BPMS (business 
process management suite) vendors. Consequently, an organization’s internal 
modeling standards may need to conform to BPMN. A good rule of thumb in looking 
at modeling standards is to have them address in some way at least the levels shown 
in the example diagram. 
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Figure 38. An Example of Process Model Levels 


3.5.1 An Example Set of Model Levels 

Processes can be modeled from many perspectives, or points of view, according to 
the needs of the organization. Process modeling has been used for strategic 
planning, improving operations, and specifying data and applications system 
requirements for many years. 
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Integrating process models 

The advent of process-focused management disciplines created the need to develop 
models that integrate these different perspectives. In a BPM environment, an 
organization’s strategy is enacted through process performance. Process 
performance links the enterprise and business process models to the workflow (or 
operations) model, which presents WHAT must be done to provide the internal or 
external customer with a product or service. The workflow model in turn links to 
the task steps — which describe HOW the work is done. And the task steps, in turn, 
must be supported by the information technology systems. 

Process repository maintains alignment 

To keep these types of models aligned, a line of visibility is needed from one type of 
model and perspective to the next in a coherent framework, typically maintained in 
a process repository. Table 9 lists the different perspectives that a process 
repository can maintain. 


This Position 

Is 

Accountable 

for 

Takes this 
Point of View 

Uses this 
Level of 
Model 

Made up of 

Executive 

Management 

Aligning 
Strategy with 
Enterprise 
Process 
Performance 

Enterprise 

Perspective 

Enterprise 
Process Model 

Processes and 
sub-processes 

Process 

Owner 

Business 

Process 

Performance 

Business 

Perspective 

Business 
Process Model 

Sub-processes 
and activities 

Operations 
Manager & 
Staff 

Overseeing 
and Doing the 
Work 

Operational 

Perspective 

Workflow 

Model 

Activities 


Table 9 


3.5. 1.1 Enterprise Process Models 

Enterprise perspective 

The members of an organization who need to see how the enterprise operates 
overall, and align overall enterprise strategy with aggregated process performance 
take an "enterprise perspective" or point of view. The enterprise perspective 
arranges the primary processes to provide a sense of their interaction and 
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integration. The enterprise point of view is captured, for each organization, in an 
Enterprise Process Model. 

Enterprise Models 

An Enterprise Process Model provides a full end-to-end, high-level view of the 
process. The model can show sub-processes as well as high-level problems and 
application systems. An Enterprise Process Model is typically a very general model 
that describes the focus of an organization and arranges the major processes of the 
entire organization. 

Enterprise Process Model components 

Generally, each high-level business process is described in more detail by its major 
components (sub-processes). An enterprise model typically has two or more levels 
of detail and serves as a high-level organizational "blueprint." The Enterprise 
Process Model may or may not include support and management processes. 

Additional Use for Enterprise Process Models 

These models have uses other than as a general classification and communications 
tool. The processes can be 

• Mapped to Key Performance Indicators (KPIs) and strategic goals in a 
process portfolio 

• Used to prioritize resources and project efforts, and 

• Mapped into a System Dynamics-type model to formulate strategies for 
alternate future scenarios or to develop high-level estimates and forecasts. 

Use of process model frameworks 

Some enterprise process modeling projects start by using one or more process 
model frameworks to create a "straw enterprise model." The "straw enterprise 
process model" provides a springboard for vetting or changing by executive 
management. Conversely, some enterprise process modeling projects begin with the 
executive and functional management’s point of view and then benchmark the 
enterprise process model against the process model frameworks. 

Process model framework examples 

Examples of process model frameworks include 

• Simple multi-level or pyramid framework 

• The APQC Process Classification Framework 

• Porter’s value chain 

• Industry-specific frameworks such as those in the energy distribution, oil and 
gas production, telecommunications, and insurance industries. 
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Frameworks categorize and group processes 

These frameworks typically categorize processes as primary, support, and 
management. Each of these categories may be used to group the major processes of 
the business. Examples of frameworks grouping primary processes include: 

• In Porter’s value chain, the primary processes are Inbound Logistics, 
Operations, Outbound Logistics, Marketing and Sales, and After-Sales Service. 

• In the APQC Process Classification Framework, the primary (Operations) 
processes are Develop Vision and Strategy (1.0), Design & Develop Products 
and Services (2.0), Market and Sell Products and Services (3.0), Deliver 
Products & Services (4.0), and Manage Customer Service (5.0). 

• In a more customer-oriented services model, the primary business processes 
can be Engage Customers, Transact Business, Fulfill Customer Expectations, 
and Service Customers. 

Process model frameworks and architecture are further presented in chapter 9, 
"Enterprise Process Management." 

3. 5. 1.2 Business Process Models 

The "process owner's" point of view 

Each business process has a process 'owner' who is accountable for the process’s 
performance and has the authority to add or remove resources that affect the 
performance of the process. The business perspective, used by the process owner 

• Provides the business context, 

• Describes the business process, and 

• Defines the scope of the business process for analysis and implementing 
changes. 

The business perspective is captured in business process models. 

End-to-end primary, support, and management processes 
Business process models built from the business perspective 

• Depict the major events, activities, and results for each of the major end-to- 
end processes, their sub-processes, and their interactions with their 
environment. 

• Typically also describe the support and management processes and how they 
interact with or support the primary processes. 

3. 5. 1.3 Workflow Models 

Operations Manager's point of view 

Managers who are responsible for monitoring performance and who look for ways 
to continuously improve operational performance take an operations perspective, 
or operations point of view. Workflow Models capture the operations point of view. 
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Describe WHAT must be done 

Workflow Models typically describe WHAT must be done for the processes to be 
completed. These models are more detailed than enterprise or business process 
models. Workflow models are mapped down to the activities (also called tasks, or 
procedures) that make up the processes. Workflow Models include the activities 
that "functions" — positions, departments, and systems — perform and the 
relationship of the activities to other functions and processes. 

Rolling up activities 

At this third level of detail it is easy to understand the activities that are performed 
in a functional business unit. By rolling the activities up to the Business Process 
level, it is easy to see how all work fits into processes and how the activities play 
roles in producing the end product of the process. 

Details "below" the Workflow Model 

The Workflow provides only a basic understanding of the detail in the business 
operation. It is often not a sufficient level of detail to resolve problems, reduce cost, 
or support automation. For these actions, it is necessary to take the workflow level 
to a greater level of detail. 

3. 5. 1.4 Task Steps 

And, yes, there are still lower levels of detail that may be needed. The key is to map 
the processes to the level that you need to support 

• What you are doing, and 

• What someone in the next phase of the process project needs to do. 

Lowest level identifies worker tasks and data requirements 

At the fourth level, the Task Steps level, the business and BPMS designers usually 
have enough detail to tie rules to specific worker or systems actions. The use of data 
is now at a low enough level of detail to design application screens and reports, and 
define edits and low level decisions. As a business process professional you may 
participate in a project where the next phase involves developing software 
applications. To support what the software developers need to do, 

• Confer with the software developers to determine the information that will 
most help them in coding and testing, and 

• Consider the use of forward-looking and backward-looking traceability 
matrices to document functional requirements. Traceability matrices ensure 
that the software will be coded and tested to support the people who execute 
the process. 

Additionally, this level is used to generate BPMS (business process management 
system) applications that manage work and automate manual "transaction" level 
data entry and use. 
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Remember to consider the requirements for any of these follow-on development 
activities and the detail needed to drive their completion, reached in the models. 

"Worker" point of view 

Those who actually "do" the work commonly focus on their tasks (also called 
responsibilities, activities or procedures) and the steps that make up the tasks. Task 
Steps identify HOW work gets done. 

Task Steps describe in detail HOW work is done 

This is the level of detail where the analyst can identify the steps that are performed 
to deliver the output or outcome of a single activity. Task Steps includes for each 
task the task trigger, steps, criteria of performance, principles to follow, materials 
and tools to use (including software), results, indicators of correct performance, and 
people who need to be consulted during or informed after the procedure is 
performed. 

Example of service Task Steps 

For example, an insurance company’s policy sales staff needs to enter a new 
policyholder into the system. The Task Steps level names the activity (also called a 
procedure, and here called a task) and lists the steps that the sales staff must 
perform to enter the new policyholder. 

Example of manufacturing Task Steps 

Another example at this level in manufacturing is "build-to-order" (BTO). Here a 
customer places an order with a sales person. The project process analyst collects 
the requirements for the "customized" product. Assuming a build from common 
parts, the analyst identifies the parts, defines the options, cuts the build order, gets 
the parts and then constructs it. 

3.6 Bottom-Up and Top-Down Modeling Approaches 

There are a number of approaches to process modeling: top-down, middle-out, or 
bottom-up. Some process model development methods call for an iterative process 
approach that requires several successive passes to developing the model. The 
approach used varies depending on the purpose and the scope of the effort. 

Bottom-up modeling projects 

Traditionally, process models were generally created for the purpose of improving 
narrowly focused functions within a single department or operation. Often the 
process has not been documented and the first step is to attempt to discover what is 
actually occurring. Bottom-up approaches, centered on very detailed activity and 
task-oriented workflows, work best for these kinds of projects. 

Top-down modeling projects 

It is now becoming more common to find process modeling applied to 
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• Improving and innovating large scale, end-to-end, cross-functional business 
processes and 

• Managing performance of these business processes. 

Some process transformation efforts begin with developing a new business model 
first and then determining what needs to be done in the business to implement the 
business model. A more holistic business process management approach, using 
enterprise-wide process models ("architectures") to align business processes with 
business strategies, is also becoming more common. These types of modeling efforts 
are best developed with top-down methods. 

Modeling approach rule of thumb 

The key is to determine the purpose of the modeling effort and then apply the best 
approach for that purpose. Once an approach is selected, consider using an alternate 
approach on a limited basis to cross-check results. For example, do some bottom-up 
analysis to ensure that the top-down model is complete. Where service-oriented 
system architectures (SOA) are being engineered, the bottom-up analysis may also 
be necessary for developing specific system interfaces to link into the larger SOA 
network. 

3.7 Capturing Process Information, and Modeling Participants 

There are several different ways to capture information for process modeling. 
Consider using one or a combination of these techniques to gather descriptions of a 
process: 

• Direct observation 

• One-on-one interviews 

• Written feedback 

• Structured workshops 

• Web conferencing. 

3.7.1 Direct Observation 

Advantages and constraints 

Direct observation is a good way to document current procedural detail. It may 
uncover activities and tasks that otherwise might not be recognized, and it can be 
effective in identifying variations and deviations that occur in day-to-day work. 

However, because it is necessarily limited to a relatively small sample size, direct 
observation may not capture the range of variations across groups and locations. 
Direct observation also entails the risk of the performers doing what they think you 
want to see, rather than what they normally do. 
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3.7.2 Interviews 

Advantages and constraints 

Interviews can create a sense of ownership and participation in the process of 
modeling and documenting business processes. This approach requires minimal 
disruption of participants’ time and normal duties. 

However, to schedule and conduct the interviews may take more overall elapsed 
time than other methods. It may be difficult afterward to build a cohesive process 
flow and to map the different views into a single view. This technique generally 
requires follow-up and sometimes doesn’t uncover all of the activities to completely 
describe the process. 

3.7.3 Survey/Written Feedback 

Advantages and constraints 

Written feedback also requires minimal time and disruption of duties. Generally, 
data may be collected in this fashion. 

However, written feedback is often prone to the same problems encountered with 
one-on-one interviews, such as taking more time, missing some information, time 
spent reconciling differences of opinion or different descriptions of the same work 
by different people, requiring follow up. 

3.7.4 Structured workshops 

Advantages and constraints 

Structured workshops are focused, facilitated meetings where enough subject- 
matter experts and stakeholders are brought together to create the model 
interactively. They offer the advantage of shortening the elapsed calendar time 
required to develop the models and give a stronger sense of ownership to the 
workshop participants than other techniques. Structured workshops can also have 
the advantage of a facilitator who may be skilled in modeling techniques not 
commonly known by process participants. 

However, due to the potential travel and expense that may be required, workshops 
may be more costly than other methods. Generally, models produced in workshops 
require less follow-up and generate a commonly agreed-upon description of a 
process more quickly and with higher quality than other techniques. 

3.7.5 Web-Based Conferencing 

Advantages and constraints 

Web-based conferencing can be employed to gain much the same benefits as face- 
to-face workshops, but they work best with smaller groups. Web-based 
conferencing can be more convenient and less expensive when the participants are 
widely distributed. 
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However, using this kind of technology effectively depends on having facilitators 
who are skilled in the use of these techniques. In workshops done this way, it can be 
more difficult to monitor and manage individual participation in the group work. 

3.7.6 Modeling Participants 

Developing process models involves a number of roles because of process models’ 
wide range of uses. Many people may be involved in creating a set of models that 
fully represents the processes. Business strategists, business managers, financial 
analysts, auditors and compliance analysts, process performance analysts, 
requirements analysts, systems analysts, or others may create different process 
models for their particular purposes. Models can be created by individuals 
expressing their personal knowledge or by groups outlining the scope and depth of 
the business they are addressing. In a more structured approach, typically there will 
be a facilitator, a modeler, and several subject matter experts involved. 

The subject matter experts may be 

• Executives expressing high-level business dynamics, 

• Mid-level managers defining monitoring and control mechanisms, or 

• Workers who actually perform the work being modeled. 

For re-design efforts, information systems personnel who develop the requirements 
for IT support must collaborate with organizational design personnel who 
determine roles, responsibilities, and reporting structures, or financial personnel 
who measure cost and value options. 

3.8 Frameworks and Reference Models 

A modeling project may require many individual models. These models have value 
both individually, as stand-alone representations, and as components of the whole 
project’s complex picture. Frameworks and reference models maximize the value 
and usefulness of the set of models within the context of the whole. There are a 
number of framework and reference model examples. 

3.8.1 Modeling Within a Framework 

A framework may range from a simple conceptual pyramid to a complex set of 
modeling products with rules governing what will be represented where. In the 
pyramid, each level of model summarizes the level beneath it and decomposes the 
level above. The pyramid may have a simple value chain at the top level that 
provides an instant overall summary of what the set of models will explain. The 
lower levels generally introduce key events, performers, operational activities, and 
more detailed process flow. Sometimes a level is included below the detailed 
process levels to show data structure and details of system or organizational 
components. 

Complex frameworks enable complex process model development 

The more complex frameworks may prescribe a standard set of products to depict 
the details of the processes under study. Very large, complex institutions often 


120 


Copyright ABPMP International 


Chapter 3. Process Modeling 


adopt frameworks intended to apply throughout all modeling efforts of the 
enterprise. Examples of these include 

• Federal Enterprise Architecture Framework (FEAF), 

• Ministry of Defense Architecture Framework (MODAF), 

• Department of Defense Architecture Framework (DoDAF), and 

• The Open Group Architectural Framework (TOGAF). 

These frameworks serve the dual purposes of helping users address extreme 
complexity within their environments and of enabling apple-to-apple comparisons 
among the different projects within the institution. The last framework listed, 
TOGAF, is a general-purpose version of a complex framework supported by The 
Open Group. Most of these seemingly different frameworks are derivatives of or 
heavily influenced by the Zachman framework, proposed by John Zachman in 1987. 

Framework management and compliance 

Management of these massive frameworks is often the role of the Enterprise 
Architect, but all Business Process Management practitioners must comply with the 
structure of the framework to avoid gaps and inconsistencies. 

3.8.2 Using a Reference Model 

Reference models ease analysis 

A reference model can serve some of the same purposes as an architectural 
framework. A reference model provides a common way of viewing some aspect of a 
process and a common way of describing it for easy analysis and comparison. 
Reference models are developed and supported by organizations and consortia for 
these purposes. 

SCOR® and DCOR SM from the Supply Chain Council 

The Supply Chain Council is a consortium that markets a reference model called 
SCOR® (Supply Chain Operations Reference). Organizations seeking a means of 
understanding their supply chains for the purpose of process analysis, comparison 
with competitors, and assessment of improvements may subscribe to this reference 
model. It provides common vocabulary and structuring of supply chain modeling 
projects while allowing great latitude in the way lower-level processes are 
described. 

Another reference model, DCOR SM (Design Chain Operations Reference) is also 
published by the Supply Chain Council. In addition to these, companies that market 
high-level process modeling environments often include sets of reference models to 
help guide effective modeling within the environment. 

3.9 Modeling Techniques and Tools 

There are many modeling tools and techniques available, ranging from use of simple 
white boards, butcher paper, or sticky-notes to sophisticated and specialized BPM 
tools that include modeling and data stores for those models and processes. Process 
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analysis can be done effectively and efficiently using any type of tool. The focus of 
the analysis or design, however, should be on the process itself, and not on the tool. 

None of these techniques is necessarily exclusive of the others; all can be employed 
in a process redesign or improvement project with different groups or in differing 
circumstances. 

3.9.1 Drawing Tools and Reports 

During or after interviews and workshops, participants can capture the process 
flows and notes using inexpensive drawing tools. Often, these drawings are inserted 
into Word documents or PowerPoint presentations as a means of reporting findings 
and sharing the results. This is a common means of process modeling used in 
organizations today. 

3.9.2 Electronic Modeling and Projection 

Using electronic drawing or modeling tools and projecting the images to large 
screens in order to capture and view the developing models has become a common 
practice today. This technique has several benefits. The model is visible and can be 
modified during a workshop. When the session is completed, no transfer to another 
toolset is required. Many tools allow the resulting models to be quickly and easily 
shared via email immediately or shortly after the session. 

Adding web-based conferencing tools enables remotely located stakeholders to also 
participate in the modeling sessions. In addition, several current modeling tools are 
repository-based, which allows the reuse of objects or patterns that have already 
been defined in previous efforts. 

3.10 Process Validation and Simulation 

3.10.1 Process Simulation Uses 

Process simulations are a form of model that provides valuable insight into process 
dynamics. Simulations require sufficient data to allow the process to be 
mathematically simulated under various scenarios, loads, or other conditions. 
Simulation can be used to achieve the following: 

• Validate a model by demonstrating that real transaction sets, when run 
through the model exhibit, produce the same performance characteristics as 
those in the actual process. 

• Predict the process design’s performance under differing scenarios (vary the 
number of transactions over time, the number of workers, etc.). 

• Determine which variables have the greatest effect on process performance. 

• Compare performance of different process designs under the same sets of 
circumstances. 
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3.10.2 Simulation Tools and Environments 

Simulations can be manual or, using process simulation tools, electronic. Process 
laboratories are often used as part of a process improvement, redesign, or 
reengineering effort. A process laboratory can perform simulations by developing 
mock transactions that can be manually executed through an end-to-end business 
process by a small cross-functional team. Simulations can be run against "as is" 
processes or designed as "to be" processes. 

Process laboratories often identify exceptions and handoffs while providing 
important insights into existing and required communication between tasks, 
functional areas, teams, and systems. Some organizations require a successful 
process demonstration in a laboratory setting before piloting or rolling out new 
processes or changes to process design. 

3.10.3 Technical Simulation/Load Analysis 

Some process simulation tools provide the ability to perform load analysis. For 
example, simulating peak, average, and valley transaction loads predicts impact on 
cycle time, resource requirements, and bottlenecks. Simulation generates data sets 
that allow many different types of process analysis. Some of the typical analyses are 
resource utilization, distribution analysis, cycle-time analysis, and cost analysis. 

Some process simulation tools can also present animations of the simulations. 
Animations may be helpful in visually identifying phenomena during performance 
that may not be readily apparent in typical analysis of simulation data sets. 

3.11 Key Concepts 


PROCESS MODELING— KEY CONCEPTS 

Process models 

• Are simplified representations of some business activity. 

• Serve as a means to communicate several different aspects of a business 
process. 

• Are used to document, analyze or design a business process. 

• Are useful as documentation for communication, training and alignment; 
design and requirements; or as a means to analyze aspects of the process. 

• Often express the "As-Is" state of the model and one or more proposals for 
change, culminating in a "To-Be” model and change management strategy. 

• May require validation by simulation. 

Perspectives 

• Different levels or perspectives of business processes are expressed by 
models showing different scopes and levels of detail for different audiences 
and purposes. 

• Process models may display several different perspectives: for example, 
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Enterprise, Business, and Operations (Workflow). 

• Each different perspective has specific types of models and composition levels 
that are best suited for the perspective. 

Notations 

• There are many different styles of process modeling notations and ways to 
develop process models. 

• Selection of a modeling notation should match the needs of the project — the 
task at hand and the needs of the project’s next phase. 

• Some notations are more versatile and apply to a broad range of process 
modeling needs. 

• Sometimes, combinations of notations match project requirements better than 
a single tool. 

Frameworks 

• If the project must comply with a specific framework, identify framework 
requirements early on. 

• Reference models are available to help guide the development of models in 
some fields. 

Capturing process information 

• When approaching a modeling challenge, the team may choose to model from 
top-down, bottom-up, or from the middle, depending on preference and 
project requirements. 

• Information capture techniques can vary widely among projects, and can 
include any combination of observation, interview, survey, and formal 
workshop; they can be in-person or online. 

• Participants in a modeling project include strategist, managers, subject matter 
experts, and different types and numbers of analysts. Process implementation 
often requires the skills of change management professionals. 
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Foreword by Elise Olding, Gartner, Inc. 

Process analysis encompasses a lot more than just flowcharts. Process analysis lives 
at various levels, from a one-page view of the organization — a conceptual level 
analysis — to very detailed and directive steps at an execution level. 

At the conceptual level it is a powerful visual technique to identify holistic, systemic 
disconnects in the organization. It can be used to engage executives to think 
differently about process, to see it as a way to make decisions about priorities and 
raise the conversation to a strategic level. At the tactical level, it is useful to drive out 
costs, standardize work execution, and contribute to more efficient routine work. 

In the layers between these two bookends live a myriad of analysis techniques that 
embrace unstructured and collaborative work to make it more effective, such as 
social network analysis (SNA), decision matrixes, and shadowing work participants. 
These are often overlooked, contributing to the view that process analysis is 
something done at an execution level in an organization. We need to rekindle the 
conversation and bring process analysis to the executive suite. 

Process analysis is a means to an end. It’s not the end! The outcome of the work 
must be to generate value for the organization. One of the common mistakes 
organizations make is to dwell too long on the "as is" analysis, documenting every 
detail. I've come across organizations with a room filled from floor to ceiling with 
process models, charts that the business partner does not want to review or 
validate. No wonder! They would take weeks to review; even I have felt 
overwhelmed trying to take it all in. 

I ask them a few simple questions: "What problems did you find? What baseline 
metrics did you document? Were there any trends or themes that became evident 
from this work? Do you have any recommendations for "quick wins"? Sadly, the 
answer to all this is "No." Somewhere along the journey, the organization has gotten 
lost and forgotten what the end game really is: delivering value to the business. 

On the flip side, effective process analysis can be an enabler. For instance, a 
company was challenged with spinning off a new organization in a very short period 
of time or risked losing a huge investment that would likely mean its demise. The 
executive management had the foresight to document and understand their existing 
processes: they used these in their day-to-day work, defining how the functions 
interact, and defining roles and responsibilities. From this starting point, they were 
able to quickly perform the process analysis, identify the actions they needed to 
take, and move forward with the "to be" implementation. They succeeded and got 
the investment — clearly delivering strategic business value. 

Whatever level you choose to analyze, from an enterprise opportunity assessment 
to a detailed as-is analysis, don't lose sight of delivering business value. Always ask 
yourself, "If I do more, will I continue to derive benefits?" Be mindful of delivering 
business value, using the right techniques for the task at hand, and always 
challenging whether further work and detail are necessary. 
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Many techniques are mainstream and are likely part of your repertoire. Some, such 
as social network analysis (SNA) or organizational network analysis, are emerging. 
Others, like work shadowing and observation, are underutilized. I would encourage 
you to explore the full spectrum of process analysis techniques, become proficient at 
using them, and understand when to employ them. 
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4.0 Introduction 

The first step in defining a new process or updating an existing one is to create a 
common understanding of the current state of the process and how the process 
achieves the stated business objectives. This common understanding is gained 
through process analysis. 

In this chapter we explore the topic of process analysis, starting with why a process 
must be analyzed and who should be involved in the analysis. Then we will explore 
the specifics of how to analyze a process, followed by discussions about the 
techniques, tools, methodologies, and frameworks that can be used. Finally, to 
ensure a complete understanding of what is necessary for successful process 
analysis, we will look at suggested practices. 

4.1 What is Process Analysis? 

Process analysis provides an understanding of the process activities and measures 
the results of those activities in meeting the organization’s goals. 

A process is a series of interrelated tasks or activities that achieve a particular end. 
In the context of business process management, a "business process" is defined as 
end-to-end work that delivers a product or outcome. This end-to-end work can 
cross functional areas and proceed through multiple organizations. 

Whether the assignment is to analyze one process or the processes that connect 
activities across business units, business partners, or the broader value chain, 
process analysis can be applied to address the current and future improvement 
opportunities. 

Process analysis is accomplished by various means, including mapping, 
interviewing, simulations, and other techniques. It often includes a study of the 
business environment, the organizational context of the process, factors that 
contribute to the operating environment, industry characteristics, government and 
industry regulations, market pressures, and competition. 

Key factors to consider are: 

• Business strategy 

• The objectives of the process 

• The key challenges in achieving the goals 

• The contribution of the process in the overall supply chain 

• The organization and business roles supporting the process. 

Those who interact with the process should agree upon information gained through 
the analysis. They need to achieve an objective and unbiased perspective, regardless 
of any existing inefficiencies. Process analysis forms the foundation for process 
design, which is the topic addressed in "Process Design" (chapter 5). 
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4.2 Why do Process Analysis? 

Process analysis is an essential tool to evaluate how efficiently the business is 
working to meet its objectives: it generates the information necessary for the 
organization to make informed decisions assessing the business’s activities. The 
principal benefit of analyzing the "current state" of the process is a shared 
understanding of how the work is done today. By creating a foundational 
assessment based on documented, validated facts, current-state analysis can help 
those engaged in the redesign of processes to better meet the goals of the business. 

For the business to evolve and adapt to change, ongoing process analysis is required 
to ensure that business needs are met. Changing government regulations, economic 
conditions, and marketing strategies can quickly result in processes that no longer 
meet their original design. 

A holistic review of the major processes within a scope of business activities begins 
with an understanding of the organizational strategy. Strategic considerations frame 
the process objectives and challenges in a broader context. Process analysis goes 
beyond the short-term tactical problems or the wish-list of the business unit. 

Process analysis addresses the fundamental process change that will impact 
achievement of organizational goals and strategies. 

Monitoring process efficiency with ongoing dashboard metrics indicates if the 
process is too costly, or if gaps exist in process performance. The analysis provides 
the measures and understanding of process effectiveness and efficiency. 

The information generated from this analysis includes 

• An understanding of the strategy, goals, and objectives of the organization 

• The business environment and the context of the process (why the process 
exists) 

• A view of the process within the larger cross-functional process 

• Inputs and outputs of the process, including internal and external suppliers 
and consumers 

• The roles and handoffs of each business unit in the process 

• An evaluation of scalability and resource utilization 

• An understanding of the business rules that control the process 

• Performance metrics that can be used to monitor the process 

• A summary of opportunities identified to increase quality, efficiency, or 
capacity. 

This information becomes a valuable management resource for understanding how 
the business is functioning and for making informed decisions on adapting to a 
changing environment. Aided by this information, management can ensure that 
process structures are optimal for attaining business objectives. 
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4.3 When to Perform Analysis 

Process analysis can be done in response to signals from continuous monitoring of 
processes, or it can be triggered by specific events. This section discusses the impact 
of each. 

Continuous Monitoring 

Business Process Management (BPM) is a committed part of an overall business 
strategy, rather than a single activity that is completed in the context of a single 
project. Managing the business by process requires that performance metrics be in 
place to monitor the processes so that they meet the identified goals of the 
organization. BPM implementation should include the capability to continuously 
evaluate processes as they are performed through the use of real-time monitoring 
tools. When deviations in process performance arise, ongoing process analysis 
allows for more decisions regarding corrective actions, or new analysis towards 
process change. 

Event-Triggered Analysis 

Events are the most frequently occurring triggers of process analysis. The following 
are just a few of the events that may trigger a process analysis. 

Strategic Planning 

Most companies regularly review and update their strategic plans. They survey the 
market and competitive landscape for new opportunities and establish new goals. 
Many of these goals impact the organization’s structure, and therefore the processes 
supporting the organizational goals. Following an update to the strategic plan, 
processes may need to be updated. 

Performance Issues 

When performance issues emerge, process analysis can assist in identifying the 
causes of poor process performance. Performance issues may present in various 
ways, from (for example) unacceptable product quality or deviations from 
regulatory requirements to existing sales support processes not keeping pace with 
new product lines. . 

New Technologies 

Advances in technology may positively or negatively impact process performance. 
As part of implementation or upgrade planning, process analysis contributes to the 
blueprint of how the new technologies will be employed. This blueprint includes an 
understanding of how and where new technologies should be applied to gain the 
maximum benefit for the organization, and what the impact will be on other 
processes. For example, implementing a new applicant tracking system should 
trigger an analysis of the downstream and parallel processes. This way, increased 
applicant flow can be managed seamlessly, and applicant experience can be kept 
uniform across alternative channels. 
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Merger/Acquisition/Divestiture 

Business mergers and acquisitions often result in disjointed production and service 
processes. In order to achieve value from mergers or acquisitions, process analysis 
is critical for establishing the capabilities required by the combined entity, while at 
the same time eliminating gaps and redundancies. In the case of divestitures, 
process analysis prior to the divestiture can help ensure that critical processes 
survive in the restructured entities. 

Regulatory Requirements 

Often regulatory bodies governing businesses will create or change regulations that 
require the business to modify its processes. By performing process analysis as part 
of meeting these requirements, a business can ensure that it complies with the 
regulatory changes in a way that manages risk, controls costs, and minimizes 
disruption. Organizations that achieve a high level of process management can, in 
many cases, look for opportunities to integrate regulation-driven processes with 
internal quality controls, and thus achieve more cost savings and robust compliance 
than organizations that look upon regulatory compliance as a costly add-on. 

4.4 Process Analysis Roles 

Successful process analysis will involve a variety of individuals within the 
organization. Examples of the roles involved in process management are further 
defined in "Process Organization" (chapter 8). 

Several key roles necessary to perform process analysis are defined below. One of 
the first steps in a process analysis is to establish and assign those roles. The 
individual or group ultimately responsible for the performance of the process, 
whether it is the process owner or the executive leadership team, should carefully 
select those who will lead and manage the team in the various roles. It will be the 
responsibility of these leaders to ensure successful completion of the project, 
including a comprehensive and accurate representation of the state of the process. 

4.4.1 Optimal Team Attributes 

A single individual can perform process analysis, but the best practice is for process 
analysis to be performed by a cross-functional team. This cross-functional team will 
provide a variety of experiences and views of the current state of the process, which 
results in a better understanding of both the process and the organization. This 
team should include subject matter experts, stakeholders, functional business 
leaders and process owners, all committed to the best possible process outcomes 
and having authority to make decisions about the needed changes. Such teams have 
the added benefit of establishing broad ownership and improved acceptance of the 
coming change. 

It is also important to make sure that enough time has been allocated for these 
resources to contribute properly to the assignment. As in any project, process 
improvement projects often fail because of a lack of time and priority placed on the 
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project. On the other hand, taking too long for the analysis phase of a complex 
project is one of the more common pitfalls. Balancing the inventory of processes and 
sub-processes involved and ensuring the process team will get the proper time 
commitment from the business units is the responsibility of the project team leader. 

The analyst or a member of the process team should have competencies in the 
process management frameworks described later in chapter 9. Firms often use 
outside consultants with expertise in process management to supplement internal 
knowledge and experience of process management methodologies. 

Once the process team is in place, the team lead must communicate the game plan 
and team-member roles. Each and every member must understand what is expected 
and agree to commit the time and effort required to make the project a success. 

4.4.2 Analysis Roles and Responsibilities 

The following describes the responsibilities of each role within process analysis. The 
organizational competencies required to support a BPM program are further 
defined in chapter 8, "Process Organization." 


Role 

Responsibility 

Analyst 

Decide the depth and scope of the analysis, how it is analyzed, 
and then proceed to perform the analysis 

Project manage or facilitate to help project advancement 

Provide documentation and final reports to the stakeholders 
and executive leadership 

Facilitator 

Lead process analysis teams 

Facilitate with unbiased view to let the group discover the 
path through the analytical techniques chosen 

Manage group dynamics 

Subject Matter 
Expert 

Provide insight into the business process 

Provide insight into both the business and technical 
infrastructure that supports the process 


Table 10 


4.5 Preparing to Analyze Process 

Process practitioners who have been involved in the redesign of large-scale 
processes know that drilling down inside a single process usually doesn’t provide 
the right level of understanding. Evaluating the activities and workflow within only 
a single process may not provide an adequate basis for improving the process. One 
needs to consider how change to a single process impacts other related processes in 
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the end-to-end process. For example, a new order entry system implemented for 
client entry may initiate a transaction, yet returns are reconciled from another 
system. This process may perform well from a customer perspective and yet fail 
because it does not provide adequate information from a financial perspective. 

To determine the scope of the project and the tools to be used, the analyst should 
consider the full context of the process activities and the value provided to other 
users and other processes. The following subsections will explore these factors. 

4.5.1 Choose the Process 

Although the processes to be analyzed often have already been determined in the 
context of an enterprise BPM engagement, there may be instances of competing 
priorities across the processes that need to be analyzed. For this reason, large-scale 
or cross-functional analysis should include governance that establishes criteria for 
prioritizing and ordering the processes to be analyzed. For example, an organization 
may identify these criteria for high-impact processes: 

• Customer-facing processes 

• High impact on revenue 

• Aligned to other processes that are high value to the business 

• Critical to coordinate with cross-functional impact 

Scoring metrics can be used to assign point values for these factors, and 
prioritization can be recommended based on the processes with the highest scores. 

Whatever method is chosen to rank them, the processes chosen should directly 
meet the goals of the organization and have a positive impact on the critical 
business result. 

4.5.2 Scope of the Analysis 

Establishing the scope of the processes included in the analysis is one of the first 
actions of the process team. Scoping is critical to decide how far the project will 
reach, how much of the broader business function will be involved, and the impact 
of any changes on upstream and downstream processes and users. 

For example, to analyze an HR recruiting process, the scope of the analysis may 
include applicant screening through the candidate selection process. A second 
possibility would be to analyze applicant screening through the employee on- 
boarding process. This latter scope would extend beyond the traditional HR 
recruiting processes to include new hire orientation, employee benefit enrollment, 
and provisioning processes. Scope selection should consider the objectives and 
desired outcomes of the analysis. If the objective were related to systems supporting 
the end-to-end process, the full scope is essential. If only the applicant screening 
process is to be analyzed, the impact on related upstream and downstream 
processes should still be considered even if those processes are not in scope. 

Once the scope of the analysis is determined, the analyst should also consider the 
depth of the analysis. Will the activity-level be adequate or should all inputs and 
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outputs be considered as part of the analysis? Too much analysis can hinder process 
creation or redesign. Avoiding analysis paralysis is critical, and will be explored 
later in this chapter. 

It may be necessary to interview a variety of individuals in various business 
functions before making scope decisions. An important consideration is that the 
more business functions and activities included in the analysis project, the more 
complicated the analysis and the longer it is likely to take. To show progress and 
manage complexity, the analyst or team may wish to break down larger processes 
and analyze sub-processes. 

4.5.3 Choose Analytical Frameworks 

There is no single right way to analyze a business process. Topics to be studied, 
methods for studying them, tools to be used, etc., are all dependent on the nature of 
the process and the information available at the time the analysis begins. Some 
projects may start with a completed and verified model that can be used for 
analysis, while others may require the development of a model (or at least 
validation of the model design.) 

The analyst, along with the process team, should review and select the analytical 
approach, methodology, and framework. Formal process improvement methods 
such as Six Sigma, Lean, or other quality methods provide tools and templates to 
assist in the review process. These methods are further discussed in chapter 6, 
"Process Performance Management." Once the analysis team selects the framework 
or methodology, it can decide what techniques and tools to use as part of that 
framework. 

If a formal method is selected, the team should have training or an experienced 
facilitator guiding the use of the analytical frameworks. It is also important to 
consider the industry and the technology related to the process. If the process is 
driven by quality measures, such as a manufacturing product line, formal methods 
supported by data and quality measures are an appropriate approach in that 
environment. If the data is not available or if the process is not structured, a 
pragmatic review may be the best approach. 

Pragmatic process analysis can be based on a standard "Plan-Do-Check-Act” 
sequence of steps. Review the process against internally developed quality 
standards and best practices. These may include minimizing handoffs, ensuring that 
each action adds value to the process, and managing data or product inputs close to 
the source. To deliver significant improvement to the organization with very low 
risk, the team should review the process to ensure that all participants accurately 
execute the same best practice. The team can drive process efficiency and 
effectiveness through a pragmatic review of the current best practice from all 
process variations currently in use. Then it can design process controls and 
guidance to ensure execution of the best practice and reduce or eliminate variations, 
exceptions, and errors. 


136 


Copyright ABPMP International 


Chapter 4. Process Analysis 


4.5.4 Performing the Analysis 

There are several well-recognized and published methodologies for process 
analysis. Some of these topics are covered in related chapters on Process Modeling 
and Process Measurement. The common activities during a process analysis are 
described below. These activities apply whether the process is an established or a 
new process and should be considered in the context of the process review. 

4.5.5 Business Context 

Achieve a general understanding of the reason for the process to exist within the 
business environment by answering questions such as these: 

• What is the process trying to accomplish? 

• Why has it been created? 

• What triggered the analysis? 

• What are the systems required to support or enable the process, and how 
sustainable are those systems? 

• Where does the process fit into the value chain of the organization? 

• Is the process in alignment with the strategic objectives of the organization? 

• Does it provide value to the organization, and how critical is it? 

• How well does it function in the current business environment and how well 
could it adapt if the environment were to change? 

• What are the risks to the process (external, environmental, or internal) and 
can the process adapt to survive those risks? 

4.5.6 Organizational Culture/Context 

Every organization has a culture that influences the internal and external processes 
of that organization. That culture includes how work is performed and what 
motivates the members of the organization to do the work. Cultural factors may lead 
to unintended consequences as new processes are put into place. Part of the 
analysis process is to understand the culture of the organization and those 
unwritten rules that determine how and by whom work is really accomplished. This 
understanding is critical for managing the organization through change. Note that 
attitudes will change as analysis and execution progresses. The interaction among 
culture, processes, and the change program requires continuous monitoring: 

• Who are the leaders in the organization responsible for the successful 
delivery of the process outcomes? How committed are they to the changes, 
and how confident are they that the improvements will be successful? 

• How are the proposed changes and improvements viewed by powerful 
service functions, such as HR, Quality Control, Compliance, Finance, etc.? 

• What is the motivating factor for quality process outcomes? How is process 
execution incorporated in the incentives that reward work output? Has the 
success of a process been measured on quality outcomes? 
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• How will the change-management training be delivered in the organization? 
Will the goals for measuring success include successful implementation of 
change? 

• How will individuals affected by or responsible for the process interpret the 
reason for the process change? Is process excellence a key competency in the 
organization or strategy? Are there attitudes, practices, or performance goals 
that provide incentives against cooperation or change? 

4.5.7 Performance Metrics 

Performance issues can be defined as gaps between how a process is currently 
performing in relation to how it should be performing to meet the organization's 
objectives. A methodical analysis can illuminate the nature of the gaps, why they 
exist, and how the situation can be rectified. A key element of the analysis is to 
identify actionable and auditable metrics that accurately indicate process 
performance. These metrics will provide indicators as to where and how a process 
should be adjusted. Key questions to ask during this discussion include the 
following: 

• Is the process meeting its performance goals? 

• What is the accepted service level for the process? Are turnaround times 
lagging behind the current acceptable targets? 

• How would we know if the process has improved? For instance, if time is the 
measurement of the process, can cost be ignored? Or if cost is the 
measurement of the process, can time be ignored? 

• How is business process monitoring managed? What are the key metrics and 
how are deviations addressed? 

• Are performance metrics or dashboards reviewed continually, so the process 
is accurately measured and monitored? 

4.5.8 Customer Interactions 

Understanding the customer interactions with the process is critical to knowing 
whether the process is a positive factor in the success of the organization’s value 
chain. Generally, the fewer required interactions between the customer and a given 
service, the more satisfied the customer. This topic should address the following 
questions: 

• Who is the customer? Why do customers choose to participate in the process 
rather than go elsewhere? 

• What suggestions do customers have for improving the process? 

• How many times does a customer interact with the process? Are there 
redundancies in the interactions? 

• How coherent is the process and the utilization of customer information, 
from the customer’s perspective? 

• What are the client satisfaction metrics? Are they within the desired norm? 

• What is the customer's expectation or objective with the process? 
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• If the process supports internal activities, what are the impacts or indirect 
effects to the customer? 

4.5.9 Handoffs 

Any point in a process where work or information passes from one system, person, 
or group to another is a "handoff" for that process. Handoffs are very vulnerable to 
process disconnects and should be analyzed closely. The following questions might 
be used as guidance: 

• Which of the handoffs are most likely to delay the process? 

• Are there any bottlenecks of information or services as a result of handoffs 
happening too quickly, or creating downstream delays? 

• Can any handoff be eliminated? 

• Where do streams of information come together, and are timing and 
sequencing accurate? 

• What means are in place to manage sequencing, timing, and dependencies 
across handoffs? 

4.5.10 Business Rules 

Business rules impose constraints and drive decisions that impact the nature and 
performance of the process. Often, business rules are created without sufficient 
understanding of the scenarios the organization may encounter, or have become 
disconnected due to changing conditions or unmanaged change. When analyzing the 
business rules of the process, consider the following: 

• Do the existing rules comprehensively cover all the scenarios and decision 
drivers that may be encountered during the execution of the process? 

• Are there logical gaps, ambiguities, or contradictions in the rules governing a 
process area? 

• Are dependent or interrelated processes governed by consistent (or 
contradictory) rules? 

• Are the business rules in alignment with the objectives of the organization? 

• Do the current business rules cause obstacles by requiring unnecessary 
approvals, steps, or other constraints that should be eliminated? 

• When and why were the business rules created, and how were they defined? 

• What would be the result of eliminating certain rules? 

• What process is in place for managing change to business rules? 

4.5.11 Capacity 

Capacity analysis probes upper and lower limits and determines whether 
production factors can appropriately scale to meet the demands. When analyzing 
the capacity of a process, consider the following: 

• Can the process scale upward? If volumes are increased, at what point will 
the process break down? 
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• How well does the process scale downward? What is the cost of the process 
when idle? 

• What happens to the process when supplies and materials are delayed or 
unavailable? 

• When the process accelerates or slows, what happens to downstream 
processes? 

4.5.12 Bottlenecks 

A bottleneck is a capacity constraint that creates a backlog. The following questions 
may help the team understand the nature of the bottlenecks: 

• What are the factors contributing to the bottleneck, and are these factors 
people, systems, or organizational? 

• Does the bottleneck occur around handoffs among multiple groups? 

• Is the bottleneck the result of an internal or external constraint? What is the 
nature of the constraint — resource availability? Rules? Process 
dependencies? 

• Are there unnecessary role specializations or organizational silos? 

4.5.13 Variation 

Although especially true in the manufacturing industry, variation in any mass 
production industry is not good. Variation inevitably slows down the process and 
requires more resources to properly scale. If the nature of the business requires 
variation as its core business strategy, then look for places where some of the 
variation can be reduced, which could save on the overall cycle-time of the process. 
Discussion topics could include the following: 

• How much variation is tolerable for the process? 

• Is variation necessary or desirable? 

• Where are the points where variation is most likely to occur? Can they be 
eliminated, and if so, what are some recommendations? 

• Can automation help eliminate variation? 

4.5.14 Cost 

Understanding the cost of executing the process helps the team prioritize which 
processes deserve early attention. Some of the discussions might revolve around the 
following: 

• What is the total cost of the process, taking into account frequency and 
circumstances of its execution? 

• Is the cost in line with industry best practices? 

• Can the cost be reduced through automation or technology improvements? If 
so, how and to what extent? 

• What would be the impact on realized value and operating margins of each 
option, in order to make this process more cost efficient? 
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4.5.15 Human Involvement 

Processes involve either automated activities or activities performed by real people. 
Automated activities generally run consistently, and when they don’t it is possible to 
find and correct the situation that is causing the problem. Activities performed by 
real people are more complex because they involve judgment and skill that cannot 
be automated. People do not always do the same task in the same way. Where 
processes or process management is not mature, people may compensate by 
individually executing functions or methods that are not documented or readily 
visible. 

The following questions can help guide the discussion around this important 
analysis: 

• How much variability is introduced by the human element? Is the variability 
desirable? Is it tolerable? Can the action be automated? What would be the 
result to the process? What would be the result to the human element and to 
the culture of the organization? 

• How complex is the task? What are the skill sets required? How are 
performers trained for the task? 

• How do the performers of the task respond to external events during the 
task? 

• How does the performer know when the task is done well? What feedback 
systems are in place to guide the performer? What can the performer do with 
this feedback — what can he or she change with this knowledge? 

• Does the performer know where the task lies in the process and what the 
results of the actions are downstream? Does s/he know what happens before 
the task? What does the performer do with variations in the inputs for the 
task? 

• How much knowledge is available to the performer to accomplish this task? 

Is it sufficient? 

• Are there signs that processes are ad-hoc rather than visible, understood, 
and repeatable? For example, do people frequently have to resort to heroic 
acts or interventions in order to get critical work done? Are people in 
ostensibly similar roles performing different work, or performing similar 
work differently? 

4.5.16 Process Controls 

Process controls are put in place to ensure adherence to legal, regulatory, or 
financial constraints or obligations. Process controls are different from control 
processes in that the former define the control while the latter define the steps to 
achieve that control. For example, the requirement to obtain a signature is a process 
control, while the step that must be performed to obtain that signature is a control 
process. The following questions may assist in understanding what process controls 
are in place: 
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• Are there any legal controls or regulatory risks that must be considered in 
relation to the process? 

• What are the environmental impacts of the process, and do those impacts 
need to be controlled? 

• Who are the regulatory or governing agencies that will regulate the process 
and do they need to be informed of the process change? 

• What competencies and roles already exist to execute and oversee process 
controls? 

• Are process control structures and procedures well documented and 
understood? Is there training and certification support to ensure 
understanding and execution? 

• Do reporting relationships ensure independence of quality or process control 
functions and the execution of the control processes? 

4.5.17 Other Factors 

The purpose of the topics above is to spark discussion about the process. Other 
discussion topics not mentioned above will naturally arise during the process 
analysis and should equally be explored. Conversely, some of the topics noted above 
might not apply to the process being analyzed. The key point to remember is that 
the analysis must encompass a variety of techniques and topics to achieve a 
complete and well-rounded understanding of the process. 

4.6 Gathering Information 

The next step in the analysis is for the analyst or team to gather as much relevant 
information as possible about the process and business environment. The types of 
information gathered depend on the business and process being analyzed. They can 
include any or all of the following: 

• Strategic information about the company, such as long-term strategy, 
markets, threats, opportunities, etc. 

• A company's performance in comparison to its peers, or benchmarked to 
other related industries 

• The rationale for the process analysis and at who's request 

• The fit of the process into the organization 

• The people who should be involved in the process analysis project 

• This information may be found using methods such as: 

• Interviews with individuals involved in the process. 

• Performance records/transaction reviews on the process (although this data 
may or may not substantiate the information learned in the stakeholder 
interviews) 

• Walkthroughs of the process, or observation of actual execution. 

• Audit reports that identify control points in the organization. 
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Interviewing 

An important method of gathering information and preparing for the process 
analysis is to interview those who have activities in or are somehow associated with 
the process. Those interviewed may include process owners, internal or external 
stakeholders (vendors, customers, or partners), those who work the process and 
those who pass inputs to, or receive outputs from, the process. These interviews can 
be in a formal face-to-face setting or can be conducted via phone or e-mail. 

Typically, the formal face-to-face setting is more productive, as it allows for greater 
dialog and discussion about what is (or was) actually happening. A group interview 
performed by a facilitator can also be effective in generating discussion about 
processes. 

Observing 

Another important method of gathering information, and similar to interviewing, is 
direct observation of the process. Either through reports or system transaction logs, 
or by observing the human interactions with the process, directly observing the 
process will help create an understanding of what the process is actually doing. 

Often, analysts find that during an analytical observation of a process, further 
questions and interviews need to be conducted to fully understand the process. 
Interviews and fact-finding should take place throughout the analysis, and it is quite 
appropriate to hold interviews during any part of the analysis process. 

Researching 

Begin by researching any documentation or notes about the existing process. This 
can include any written documentation created when the process was created, 
transaction or audit logs, process diagrams, etc. Should this information not be 
available, the analyst may wish to request written descriptions of the process from 
the key stakeholders and actors in the process. 

4.6.1 Analyzing the Business Environment 

To fully understand a business process, the analyst must also understand how the 
business and the business environment interact. A business environment analysis 
includes understanding the organization’s market and external factors affecting it, 
the customers' demographics and needs, business strategy, the suppliers, and how 
work transforms to meet the needs of the customers. 

As the business environment changes over time, so must the organization's 
processes. The business analysis informs the analyst of the environmental changes 
that have taken place since the process was first created and can help explain the 
reasons for poor performance of a process. Understanding these relationships is 
important for discerning how processes might need to change. 

There are as many methods to analyze the business environment as there are 
researchers and consultants within the field of business management. The following 
are a few common techniques used in analyzing the business environment: 
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Benchmarking 

During the analysis it is good practice to compare the performance of a process to 
similar processes in the industry. These processes also can be compared to similar 
processes in different industries. This information can be gained through industry 
surveys and other industry roundtable or exchange groups. 

Another type of benchmarking technique is comparison of the subject organization 
with its direct competitors — that is, to analyze how processes compare to 
competitor processes and consider competitive advantages. A "S.W.O.T." (strengths, 
weaknesses, opportunities, threats) analysis is part of this investigation. 

Competitive analysis techniques include obtaining information from public sources, 
industry trade associations, web sites, customers, or consulting firm surveys. 
Essential process characteristics from the organization are then benchmarked 
against those of competitors. 

The final type of benchmarking analysis identifies processes that are similar to the 
process being analyzed but that exist as best practices in other industries. For 
example, online retail companies adopt 'best practices’ in order processing; as 
online order-entry for a retail firm is redesigned, an analysis of broader industry 
best practices can be reviewed for other types of ordering processes. The retail firm 
is apt to discover new processing ideas since they are researching companies 
outside their industry. This analysis allows the process designers to escape the 
"group think" syndrome that often exists when organizations look only within their 
own company or industry. This type of analysis can help promote transformational 
change in an organization. 

Understanding and analyzing these benchmarks in relation to the processes being 
analyzed will help the analysis team understand the performance potential of the 
process and its weaknesses in achieving that performance. 

4.6.2 Analyzing Information Systems 

Often, automated process discovery will find that the major causes of inefficiency 
include significant process variability across different users, process restarts and 
rework, exceptions and errors. 

A few common analytical techniques are described below: 

Data Flow Analysis 

Data flow analysis seeks to understand how data flows through a system and how 
data items interact at points through the process. Data on transactions processed 
through the system will give insight into the volume and complexity of many types 
of transactions. Data flow analysis provides a unique view of what happens to the 
data during the process and enables better understanding of the volume of standard 
and exception processes. 

This type of analysis helps the analyst uncover bottlenecks, unneeded queues or 
batches, and interactions that do not add value. Data Flow Analysis also helps 
uncover business rules that should or should not be applied, based on the data. Such 
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business rules might add insight into the routine rules that could be automated and 
applied as standard transactions, as well as those representing exception processes. 

Business Rules 

Business rules were discussed as one of the elements in understanding the 
organizational culture. They are covered in chapter 10 in greater detail. 

Many automated systems explicitly or implicitly incorporate business rules into 
their configurations or hard-coded algorithms. These rules often are essential to 
smooth business operations, yet are poorly understood by the people whose work 
depends on them. This is especially true in organizations that have not achieved 
disciplined process documentation and change control. In such organizations, 
institution knowledge is lost as staff turns over, and the only evidence of these 
important rules is how they are coded on-system. 

The challenge is to work with technical analysts and application support to uncover 
these often hidden troves of rules information. The next step is to reverse-engineer 
the rules from the configurations. This has to be done in close consultation with staff 
that have functional expertise related to the rules. 

Systems Documentation and Suitability for Use 

How software systems are used — whether custom, configurable, or off-the-shelf — is 
an important source for finding processes. Often, systems and how they are used is 
not documented. The discovery process should thus include identifying systems- 
dependent processes and then reverse-engineering those processes and rules based 
on how the system is actually coded, configured, and used. 

Do not assume, however, that the systems currently in use are the best solution for 
the job. There can be many clues that this is not the case. People may view the 
system as an impediment rather than a job support; or you may find that people 
implement workarounds and manual steps to compensate for the inadequacies of 
the system. The analyst must strive to understand how staff members relate to their 
automated tools. This can be essential to understanding what the processes really 
are, and where any disconnects occur. 

4.6.3 Analyzing the Process 

The following analytical instruments are often used to extract information about a 
process, such as how long the process takes, the quantity of product through the 
process, the cost of the process, etc. The process analysis team should look for those 
instruments that will best explain the type of data desired for the process being 
analyzed. 

Creating Models 

Process models are often used to show processes and the various interactions with 
one or more of them. Chapter 3, "Process Modeling," is devoted to various 
techniques that can be used to create process models. 
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Cost Analysis 

Also known as activity-based costing; this analysis is a simple list of the cost per 
activity, totaled to comprise the cost of the process. This analytical technique is used 
frequently by businesses to gain an understanding and appreciation of the true cost 
associated with a product or service. This type of analysis is often used in 
conjunction with other analytical tools and techniques discussed in this section. 

This analysis is important to the process analyst in order to understand the real 
dollar-cost spent on the process so it can be compared to the dollar value in the new 
process. The goal may be decreased costs, or — if increased efficiency — the value of 
the increase in production compared against the cost. 

This type of analysis can quickly uncover bottlenecks in business processes as they 
interact with the system. As most processes are dependent on some sort of 
automated system, the interaction and cost per transaction of the system is critical 
to understanding the system. 

Root-cause Analysis 

A root-cause analysis is a 'post-mortem' technique used to discover what truly 
caused a given outcome. The intent of the analysis is to prevent undesirable 
outcomes from happening again. 

Finding the root cause for an outcome is not always as easy as it may seem, because 
there may be many contributing factors. The process of finding the root cause 
includes data gathering, investigation, and cause-and-effect relationship 
diagramming to eliminate outcomes. This process is much easier when the outcome 
is isolated and can be easily reproduced. 

Sensitivity Analysis 

A sensitivity analysis (also known as a "what if" analysis) tries to determine the 
outcome of changes to the parameters or to the activities in a process. This type of 
analysis will help the process analyst understand the following characteristics of the 
process: 

• The responsiveness of the process. This is a measurement of how well the 
process will handle changes to the various parameters of the process. Such 
parameters would include an increase or decrease of certain inputs, and 
increasing or decreasing the arrival time of certain inputs. This will enable 
the analyst to know how quickly the process will flow, how much work the 
process can handle, and where the bottlenecks will occur, given any set of 
parameters. 

• The variability in the process. This is a measurement of how the output of 
the process changes with the varying of parameters in the process. Often, one 
of the goals in performance improvement is to eliminate variability in the 
outcome. Knowing how variability in the parameters affects the outcome is 
an important step to understanding the process. 

The sensitivity analysis is instrumental in understanding the optimal performance 
and scalability of the process and the effects of any variations in its parameters. 
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Risk Analysis 

Similar to the sensitivity analysis, the risk analysis examines the effectiveness of 
process control points. Examples of these control points include validating client 
identity or, for purchases, client credit ratings. These steps and the business rules 
surrounding them establish limits before the process can proceed. These activities 
and business rules must be in place as the process is designed. The risk analysis 
aims to consider what would happen to the process should any of these scenarios 
happen, and ultimately what the outcome would be to the organization. 

4.6.4 Analyzing Human Interactions 

Many processes require some type of direct human involvement to ensure their 
progression. These are the processes that usually require the most analysis in order 
to understand. The following are techniques that can be used to assist the analyst in 
creating that understanding: 

Direct Observation 

One technique is to directly observe those performing the process. Much can be 
learned by just watching process performers in action. They are the experts and 
generally have found efficient ways to do what they have been asked to do within 
the constraints that have been imposed on them. After the analyst feels s/he 
understands the basics of what the performer is doing, it may be helpful to ask a few 
questions about actions that are not understood. 

The primary advantage of direct observation is that the analyst can see the current 
process firsthand. An analyst’s presence, however, can be an influence causing 
slightly altered behavior by the performer. Sufficient observation time should be 
allowed for the performer to become comfortable with the observer who is 
watching and taking notes on the action being performed. Care should be taken to 
ensure that the work observed represents the routine nature of the job, rather than 
a carefully selected sample of transactions. The processor selected for the analysis 
should also represent the typical performance level for the processor-group and not 
(for example) the highest level of performance in the group. Performance is also 
modified when the subject is being observed; this is called the Hawthorne impact. 
These conditions should be considered as the observations are performed. 

Specific things to learn from this kind of analysis are: 

• Does the performer know how the thing s/he does impacts the results of the 
overall process and customer of that process? 

• Does the performer know what happens in the overall process, or is s/he 
simply working within the known procedures of the specific role? 

• What criteria does s/he use to know whether, at the end of each performance 
cycle, the work performed is satisfactory? 

The analyst should also demonstrate how the actions performed by the human 
interaction impact the outcome of the process. 
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As a worker may work seamlessly from transactional-based to knowledge-based 
work, more questions may be needed to uncover and document the "knowledge- 
based” observations required for the human interaction. In addition, knowledge- 
based tasks should be evaluated as potential business rules to be captured and 
potentially automated. 

Apprentice Learning 

Learning what is being done, rather than merely watching, offers deeper levels of 
comprehension of a performed action. When possible and useful, the performer 
should teach the analyst the job. This can yield additional detail about the process. 
Teaching causes the performer to think about aspects of the process that might 
occur subconsciously. 

This method is usually performed on repetitive tasks such as order fulfillment. By 
performing the process, the analyst has a greater appreciation for the physical 
aspects of the activity and can better assess the details of the operation. 

During the apprentice-learning period, it is useful to have a second analyst observe 
the learning process and the initial actions of the apprentice. 

Activity Simulation 

One method of analyzing human performance is to simulate the activities involved 
in a process. The activity walk-through can be accomplished in a variety of ways: 

During the interview, an analyst may carefully step through each activity, observing 
its inputs, outputs, and the business rules that govern its behavior. 

In a process workshop, members engaged in the process meet and talk through the 
process. In sequence, the person representing the process-step discusses in detail 
what is done, how actions are governed, what steps are performed, and how long it 
will take. Handoffs from one performer to the next can be detailed to ensure that all 
required inputs are available for the next activity, and from what source. It is 
advantageous to have the process model available in a format that all can see, so 
those who are not directly involved in an activity can follow the process in the 
model and note any deviations. A facilitator engaged to conduct the workshop can 
help the participants engage in productive sessions and process discovery. 

A bonus variation is to record on video the group walk-through for later analysis 
and discussion to ensure that all important elements have been captured. 

The latter two variations involve participants in the real process who are the real 
experts, offer the best advice and means for improvement. 

Workplace Layout Analysis 

A workplace layout analysis is mostly a physical analysis of a work place, assembly 
line, or manufacturing floor space. The activities used to analyze workflow and the 
movement of materials and resources as the work is completed are further detailed 
in the concepts of Lean. The focus on reducing extra motion, waiting time, and 
transportation steps can add value as the work is redesigned. This type of analysis 
can uncover unnecessary motion for material-related bottlenecks, disconnections, 
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and duplicated efforts as work items are transferred from one physical location to 
another. 

This analysis can also be useful for any process that involves a physical space where 
activities are performed and handed off between individuals, groups, workstations, 
etc. 

Resource Allocation Analysis 

This analysis is focused on the resourcing required to complete the process. It takes 
into perspective the skills of the resources and abilities of tools or other automated 
systems in meeting the needs that a process demands. It generally seeks to 
determine why, from the following perspectives, an activity takes a given amount of 
time: 

• Capabilities of the resource. This analysis considers what the resource is 
capable of accomplishing and asks whether the skills and training are 
sufficient to perform the activity adequately. Comparisons can be made to 
similar resources doing similar tasks to validate whether the resource in 
question will accomplish what could be accomplished in the same amount of 
time. 

• Quantity of resources. This analysis examines whether the resource is 
constrained. For resources engaged, such as a piece of equipment, the 
analysis examines the specifications of the equipment to ensure that it is 
being used within the tolerances given by the manufacturer. For human 
resources, the analysis examines whether the resources are fully engaged 
and mastering the key elements of the job, or are underutilized, in some way 
becoming a bottleneck. 

Often, companies working through a process improvement initiative undergo a 
resource allocation analysis only to discover it is not the processes that are 
inefficient, but the resources as currently utilized. By performing this type of 
analysis, the analyst can often uncover several bottlenecks that can be improved 
with little cost or change in infrastructure. If the bottlenecks are related to staffing 
or organizational structure, changes will depend on the organization's ability to 
manage human resource issues. 

Motivation and Reward Analysis 

One commonly overlooked analytical component is the examination of the human 
motivational and reward systems in place for the process. The reward system could 
include any number of rewards such as a job structure and promotional 
opportunities for mastering additional skill sets and competencies, bonuses, 
emotional satisfaction, etc. Understanding those motivations and rewards when a 
process is analyzed will help uncover unseen disconnects and bottlenecks in the 
process. 

Further, the motivation and reward analysis should also consider what rewards 
should be in place to positively affect any new process or activity that is introduced. 
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4.7 Document the Analysis 

The final step in an analysis is the generation of reports and other documentation 
regarding the findings. The documentation of the analysis serves several purposes. 

It acts as a formal agreement among those that participated as to the accuracy of the 
analysis. Next, it is the basis for presenting the results of the analysis to 
management. 

This documentation could include any of the following items, as appropriate for the 
process that was analyzed: 

• Overview of the current business environment 

• Purpose of the process (why it exists) 

• Process model (what it does, and how it is done) including inputs to and 
outputs from the process 

• Gaps in performance of the process 

• Reasons and causes for the gaps in the process performance 

• Redundancies in the process that could be eliminated, and the expected 
savings as a result 

• Recommended solutions or other considerations. 

The documentation should clearly present an understanding of the current state and 
include deliverables that provide the information necessary to consider process 
change. 

4.8 Considerations 

The following section outlines several of the critical success factors, suggested 
practices, and pitfalls to avoid during a process analysis. 

Executive Leadership 

One of the most important factors to ensure success during any stage in a process 
improvement project is the support and direct encouragement of the executive 
leadership team. Ideally, executive leadership should be the primary sponsor behind 
the process improvement project. At the very least, the executive leadership team 
must commit to providing full support to the process redesign or improvement 
project. 

To convince the leadership team of a process improvement project’s benefits, it may 
be necessary to demonstrate gains through a few small projects. Once these small 
gains have been proven and sustained over time, it is easier to obtain support for 
larger process improvement projects and, eventually, managing the entire business 
through process management. 

Organizational Process Maturity 

If the process analysis is part of a broader review of all processes within the 
business function, it is important to understand the maturity of the organization in 
relation to the Business Process Maturity scale defined in "Enterprise Process 
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Management," chapter 9. Understanding the maturity of the organization in process 
management will help define the level of analysis in preparation for broader process 
transformation. 

The following example illustrates a five-level process maturity model. Using 
common factors such as process alignment, process automation, and integration 
with other processes, ratings can be assigned to develop a rating for each process. 
Once these ratings are known across a broader business function, the model can 
serve as the guide for future transformation planning. 


Aware - Processes are managed within the individual unit or 
department. Minimal cross functional participation. 


^ A 


Aligned - Processes are owned with common goals and objectives 
across broader business unit. Collaboration on process change. 


Integrated - Processes managed with single owner and 
commmon vision; process objectives aligned and continuously 
improved. 


A 


Optimized- Process managed consistently at the enterprise 
level; change is simulated across the end to process. 


Defined - Process documentation is owned and updated; shared 
understanding across business groups. Informal process planning. 


Figure 39. Process Maturity Model 

Evaluating process maturity is important for any holistic review of the complete 
business function. Process maturity is an essential input into the roadmap for 
executing change initiatives such as major technology investments or enterprise 
process planning. Process maturity considerations will also factor into opportunities 
for process transformation and serve as a basis for future strategic initiatives. 

Avoid Designing Solutions during Analysis 

Although mentioned previously in this document, it deserves repeating. Often 
during the analysis process, solutions to process problems will arise. Members of 
the process team will want to explore these solutions and sometimes begin work 
immediately on designing a solution. This practice is analogous to beginning 
construction on a building with only part of the blueprint. 

At the same time, it is important not to discourage suggestions for solving process 
problems that are uncovered during the analysis. One practice is to create a 'parking 
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lot’ of suggestions based on the items discovered. When it is time to design the new 
process, address those items on the list as part of the larger true process design. 

Paralysis from Analysis 

Experience has shown that it is possible to do too much analysis. Some members of 
the analysis team will want to document each trifling detail about each activity that 
happens in a process. Such detail can quickly become tedious and those involved in 
the process improvement team can lose interest. Process analysis participants and 
management may become impatient with the lack of progress. If the analysis is 
prolonged, members assigned to the project may not be available for the remainder 
of the project due to other commitments. 

In order to be effective, the progress of the analysis should be quick and readily 
visible to all members of the team, as well as to the leadership team supporting the 
project. A good consultant or facilitator can also assist in moving the team forward 
and, if progress is slow, should be considered. 

It is also critical to ensure that the scope of analysis is small enough to be 
manageable. Be sure to factor process areas into chunks small enough to allow each 
team to readily comprehend the processes within their scope and make rapid 
progress. 

Proper Time and Resource Allocation 

Often, resources assigned to improvement projects have other mission-critical 
responsibilities within the organization. Although it is wise to get the most 
knowledgeable individuals on the process analysis team, these individuals may not 
be able to dedicate themselves sufficiently to keep the project moving forward. 

Fortunately, company leaders are often aware of this problem and decide to retain 
consultants or contractors to assist in the process improvement so the management 
team can continue running the business. However, while consultants can help in the 
execution of the process improvement project itself, consultants are not a good 
substitute for those who actually own or execute the processes themselves. Advice: 
work with management to gain access to critical practitioners and to mitigate any 
work impacts. It is critical that those who are assigning the resources allow those 
resources appropriate time away from daily responsibilities to complete the project. 

Customer Focus 

One of the biggest factors leading to a successful analysis is consideration of the 
customer within the process. Even if a process appears to work within the context of 
the organization, it may not necessarily work for the customer. Inevitably, if the 
customer is neglected in the process, customer satisfaction will be sacrificed and the 
process will not lead to the increased performance expected. 

There is a growing trend toward considering inter-departmental relationships as 
service-oriented relationships. Although the same 'customer service'-oriented 
interactions should take place within departments of the organization as in the 
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interactions with customers, it is important to realize that transactions between 
departments are not customer transactions unless the departments are separate 
business units that also serve customers external to the business in the same way. 
However, processes between departments should still be examined for 
improvement, with the 'true' customer as the focus of those improvements and how 
they will indirectly impact the customer. 

This concept can be difficult to understand when, for example, the organization is 
trying to improve an internal function such as payroll processing. When considering 
how payroll processing affects the customer, the analyst will examine how the 
reduction of overhead expenses can be used to decrease costs for the customer. This 
analysis result illustrates the relationship between everything in the organization’s 
operations and its direct or indirect effect(s) on the customer. 

Understanding Organization Culture 

As stated previously in this chapter, understanding the culture of an organization is 
critical to the success of the analysis and ultimately to the design and 
implementation of the new process. Following are two of the key elements that 
should be addressed when considering the culture of the organization. 

Consideration of these topics during the analysis stage will help ensure that the 
analysis presented not only represents the true organization, but that it is accepted 
by the organization. 

Fact-Based Analysis 

If any change to a new process is to be successful, it is vital that the analysis avoids 
directing any accusation of problems that exist in processes toward any individual 
or group. Stating facts without placing blame is critical. By eliminating blame and 
simply stating the facts, the analysis will more likely be accepted as a correct 
understanding of the current state and will avoid any assignment of blame that can 
result. 

Potential Resistance 

Process analysis could be considered by members of the business unit as a potential 
disruption carrying unknown elements of change. The process owner may also view 
the analysis as a criticism about the way the process has been managed. 

Business units and process owners may therefore avoid opportunities to participate 
in the analysis. In instances such as these, it is vital for the leadership team to 
negotiate the situation, communicate the need for the analysis, and support the 
outcomes as an essential element of keeping the business competitive within the 
industry. 

Involving the process owner in the analysis process is a key factor in overcoming 
this issue. 
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4.9 Conclusion 


Process analysis creates a common understanding of the current and/or future state 
of the process to show its alignment with the business environment. It is 
accomplished by the employment of a professional analyst or a team of individuals 
to perform the analysis. Using several different techniques, frameworks, 
methodologies, and suggested practices, the analysis team documents the business 
environment and creates models and other documentation to illustrate the 
workflow of the various activities involved with the process and their relationship 
to the environment in which the process operates. The team then uses this 
information to identify opportunities for process improvement or redesign. 

Process analysis is a commitment that allows organizations to continuously improve 
their processes by monitoring process performance and thereby improving the 
performance of the organization. 


4.10 Key Concepts 


Process Analysis — Key Concepts 

Process analysis serves to create a common understanding of the current state of a 
process and whether it is meeting the goals of the organization within the current 
business environment. 

Process analysis can occur at any time the organization considers it necessary but 
the organization should have a goal to continuously monitor processes as opposed 
to waiting for single events to trigger a process analysis. 

The various individuals that assist with process analysis include executive 
leadership and a cross-functional team comprised of stakeholders, subject matter 
experts and process analysis professionals. 

Process analysis should first focus on the high value or high impact processes. 
These are defined as: 

• Customer facing processes 

• High impact on revenue 

• Aligned to other processes that are high value to the business 

• Critical to coordinate with cross functional impact 

The analysis should find an explanation of the interaction of the process within the 
business and find any of the following disconnections: 

Performance goals not being reached 
Failing customer interactions 
Handoffs that create disconnections 
Process variations 
Bottlenecks 

Many analysis techniques can be used during the process analysis to obtain the 
type of information necessary for the process being analyzed. The techniques used 
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should consider human performance, systems, technology, modeling tools, 
business environment, and strategy assessments. 

Process methodologies and frameworks ensure the process analysis follows a 
commonly accepted path to achieve best results. Process analysis can follow 
formal analytical methodologies or a pragmatic review of the standards for best 
practice execution. 

Critical success factors for a successful process analysis include: executive 
leadership, considering metrics, benchmarks, customer interactions, and cultural 
considerations. 


155 


Copyright ABPMP International 




Chapter 5 


Process Design 



Copyright ABPMP 


Chapter 5. Process Design 


Foreword by Jim Sinur, VP, Gartner, Inc. 

As organizations move forward with business processes management (BPM), they 
will be faced with the prospect of designing processes. It makes no difference 
whether the process can be modeled ahead of time or not; the basics of process 
design and the resulting models will play heavily in the representation of the 
processes. There are three basic process design approaches: the Pre-modeled 
Business Process, the User Interface (UI) Influenced Process approach, and finally 
the Automated Business Process Discovery (ABPD). These approaches range from 
planned to actual behavior, but they represent the resulting process in a model 
(complete process or process snippets). 

A process representation, planned or actual, gives the context for work performed, 
the policies in effect, the process context at the time of execution, the data or 
information leveraged, the analytics leveraged, the patterns responded to, the 
resources leveraged to completion, and the goals and key performance indicators 
(KPIs) in effect. A process design, as indicated above, is much more than a simple 
model of work flowing, but process design does represent the flow of intelligence 
applied to work in either a static or dynamic model. 

A process design can be simple and static, but it tends to evolve, taking on an 
intelligent and dynamic nature as the business context gets more complex and 
differentiating. 

Pre-modeled Business Process 

The first and most popular form of process model, as of this writing, is pre-modeled 
business process. While this chapter focuses mostly on this approach, it is important 
to understand there are other alternatives that can be used as well, as indicated 
below. This chapter details a better practice for pre-modeled business processes, so 
good reading is ahead for organizations that are taking a planning approach. In this 
approach, process models are created ahead of execution, and changes occur as new 
paths, exceptions, and new steps are discovered, added, changed, or deleted. 

User Interface Influenced 

While designing process models in a collaborative fashion is helpful, some 
organizations prefer to "test drive" a user interface and incorporate the process flow 
into the UI. This is helpful for those who are tactile and prefer to see something 
operate, rather than visualize steps, paths and decisions. This is a great way to 
prototype a process model, or build reality into a pre-modeled approach that closely 
follows the UI experiential approach. 

Automated Business Process Discovery 

This approach can vary in tactics, but it is based on actual activity. It could be as 
simple as watching workers using existing open-ended (i.e., menu-driven) 
applications to create a full process model. It could be as complex as watching 
knowledge workers (employees and or stringers) collaborating on a case and 
presenting alternative process snippets, thus generating multiple success patterns. 

A common use is creating a process model from multiple log records and sources to 
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create a complete process. We see this approach augmenting adaptive case 
management, where a process or portion of the process is quite unstructured except 
for the desired milestones and outcomes. 

There are multiple ways of accomplishing process design. It is imperative to 
understand what ways work in your culture and situation. 
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5.0 Introduction 

This chapter focuses on the design or redesign of current processes to improve 
efficiency, effectiveness, quality and consistency. It discusses the key aspects of 
information discovery, process design preparation, key activities in process design, 
and key success factors for the initiative. 

The discussion is not intended to present or promote a specific methodology or to 
support any standards; "how to" discussions are provided to help the reader 
understand an approach or a technique. 
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Figure 40. Process Design Activities 


As with all projects, formal project management is critical to success. This vital part 
of delivering a successful change is itself a specialized skill and is not addressed in 
this chapter. However, formal, focused project planning and management is 
important for the successful execution of a process redesign or initial design, and we 
urge that management controls be used to help promote success. For project 
management hints and assistance, readers are advised to contact the Project 
Management Institute. 

The discussion in this chapter will touch on the six activities in Figure 40, but it is 
not limited to these activities nor is the chapter organized around them. 

5.1 What is Process Design? 


Process: A combination of all the activities and support needed 
to produce and deliver an objective, outcome, product or 
service — regardless of where the activity is performed. 
Activities are shown in the context of their relationship with 
one another, to provide a picture of sequence and flow. 


Processes are made of groups of activities or behaviors performed by humans 
and/or machines to achieve one or more goals. They are triggered by specific events 
and have one or more outcomes that may result in the termination of the process or 
a handoff to another process. In the context of business process management, a 
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business process may cross any functional boundary necessary to completely 
deliver a product or service. 

Processes are comprised of subprocesses, each of which produces a specific part of 
the end product, service, or deliverable. These subprocesses also have a flow 
relationship. But, because processes are generally cross-functional and wind their 
way through several business units, any process design must look at both the 
process-level work (high-level view) and the process activities that are performed 
within different business units. Because any single business unit can be expected to 
perform similar work from a variety of processes, the work in any business unit will 
support a range of processes; thus, — any change to the business unit’s activity will 
have a far-reaching effect. Because activity in the business unit is organized for 
efficiency, not by subprocess or business function, the direct link of any activity back 
to the process or processes it supports has become blurred. Consequently, changes 
are not easily related to process, and impact may be hard to define. At this level in 
the business, the work’s efficiency, rather than the process, becomes the focus. This 
is the workflow level. 


Workflow: The aggregation of activity within a single Business 
Unit. Activity will be a combination of work from one or more 
processes. Organization of this work will be around efficiency. 
Modeling will show this work as a flow that describes each 
activity's relationship with all the others performed in the 
Business Unit. 


To be effective, any process design must consider activity at both the process and 
workflow levels. The reason is that it is possible to maximize the efficiency of the 
process and seriously impair the efficiency of the workflow level. Of course, the 
reverse is also true, so care must be taken to consider the impact of change at both 
levels to avoid creating problems. 

5.1.1 Process Design 

As we have seen, process design is the formal definition of the goals, deliverables, 
and organization of the activity and rules needed to produce a product, service, or 
outcome. This definition includes the ordering of all activity into flow based on 
activities’ relationships to one another, and the identification and association of 
skills, equipment, and support needed to perform the activity. 

Also, as noted above, because it is cross-functional, a process's activities are 
performed in multiple business units and by many different people. Each business 
unit thus performs activities from several different processes. These activities are 
usually grouped by the type of work needed to perform them and they are executed 
in an order that promotes efficiency. This work and its ordering in a business unit is 
workflow. It is important that the process design team recognize this difference 
between process and workflow. 
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In approaching a process design (or redesign), the team will need to understand the 
end-to-end process, the business units that are involved in its performance and the 
way its activities are executed in the various business units (see Figure 41). This is 
important because teams that focus on any one level to create designs may impact 
or damage activity at other levels. For example, it is possible to eliminate seemingly 
unneeded work in a given business unit that will have a significant impact on 
another business unit downstream. It is also possible to make process-level changes 
that compromise quality or the ability to deliver a product in a given business unit. 
However, with an understanding of how the process functions and how its activities 
are grouped with those of other processes within the various business units, a new 
design can be evaluated at all levels to ensure that improvement actually is 
beneficial for everyone. 



Figure 41 


In this discussion, we will assume that this process-business unit-workflow 
perspective is a given, and for simplicity’s sake we will refer to this multi-level 
grouping of activity as "process." When referring to work within a business unit, we 
will refer to it as "workflow." This relationship is indicated in Figure 41. 

This distinction represents a realization that the work "process" is often used to 
describe any work or any activity. We have found that this use of the term 
compromises the fundamental belief that process is cross-functional and represents 
an end-to-end aggregation of work that produces a product or service that is 
consumable by a customer. 

Process design thus involves the identification and ordering of the functions and 
activities in a business operation, along with all supporting mechanisms, product 
production technology, and computer application systems. The outcome of this 
design is the creation of specifications for new and modified business processes 
within the context of business goals, process performance objectives, business 
applications, technology platforms, data resources, financial and operational 
controls, and integration with other internal and external processes. Both a logical 
design (what activities are performed) and a physical design (how the activities are 
performed) are included as deliverables. 
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In most cases process design involves creating and understanding the current 
process and its subprocesses, and examining how the operation of can be improved 
or fundamentally changed to provide a desired result. This result can be anything 
from cost reduction to an improved ability to change rapidly — as in a move to a 
continuous improvement program. Importantly, however, the designed result 
should be measurable — i.e., something that can be measured. It is this measurement 
that will ultimately determine the quality and success of the new process design. 

5.1.2 Why do Process Design? 

Processes define the flow of activity and the blueprint of how activities in the work 
operations come together to produce a product or service. As such they define what 
will be done and how it will be done. 

But few processes in operation today in most companies have been formally 
designed. Most have simply evolved over time to deliver specific products or 
services. This evolution has normally been based on a need to "get the job done." 
And, because every business is dynamic, the need "to get the job done" has required 
constant changes in the work and the way it is performed. Therefore, in spite of 
being operationally successful, most processes are thought to be less efficient than 
they could be, and in most companies this efficiency concern has both cost and 
quality implications. 

This is generally acknowledged to be true even in companies that have been 
involved in business modeling in the past. The simple fact is that few companies 
understand work at a level higher than a business-unit level in other than 
conceptual terms. Although there are exceptions, few companies understand their 
processes at a detail level — even those that use Business Process Management 
Suites (BPMS) to formalize their business modeling. The reason is that BPM and 
Business Analysis projects in most companies have tended to be focused at the 
tactical level. However, this is starting to change and we have seen some firms 
actually tying business architecture to process architecture and redesign in order to 
better understand the operation of the business and how work ties to strategy. 

The result of this generally recognized need for improvement is a move to 
understand the actual business operation and not just a theoretical concept of how 
the business should be operating. This need is driving a growing belief that effective 
change must be based on a process view of activity and an understanding of how the 
processes in the company really operate. T o support this understanding of the 
operation, most improvement teams begin with the creation of "As Is" or "Current 
State" models of the business. Changes are based on these models and a new design 
called a "To Be" or "Future State" model. In this chapter, the "To Be" redesign is 
discussed in the section titled "Process and Workflow Design." 

Most BPM practitioners understand the need for these models to illustrate how the 
business works today, to identify improvements, and to design how the business 
will work in the future. However, while most people have been exposed to business 
models, many in business and IT have not been exposed to the models or techniques 
in this chapter. Many others will also not have been exposed to the need for problem 
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definition, rule definition, performance measurement, simulation modeling and 
more that will be discussed below. 

Unfortunately, some will have been taught the approach of starting with a blank 
sheet of paper and designing from theory, an ideal operation. The problem is that, 
without understanding the current operation and its problems, rules, and 
challenges, the team will often forget critical business activities, fail to understand 
the causes of problems, and will tend to create designs that are not cost- or 
operationally effective. The saying "those who ignore history are doomed to repeat 
it" applies to business redesign, just as it does to the larger society. ABPMP believes 
strongly in the need to understand the past and the current business, production, 
and technical capabilities and environment in the company. We also believe strongly 
in the need to understand the culture of the company and the ability of the company 
to absorb change. These factors are important in any new design. 

5.2 Process Design Foundation 

In this chapter we will look at 1) process definition, 2) how it breaks into sub- 
processes, 3) business functions, 4) Business Unit workflows and 5) operational 
scenarios. The actual design of a new process, by definition, must consider activity 
without regard to the business units that perform the work. This is due to the cross- 
functional nature of process. The high-level process considerations must also be 
viewed at the subprocess level where the work is aggregated into business functions 
and then aligned to the business units that perform them through the activities that 
define them. Within the business units, the business function’s activities will be 
combined with activities from other business subprocess functions to form 
workflows. The actual redesign must consider change at all these levels. If all are not 
looked at, change may be created that is damaging in a broader sense and can 
actually hurt downstream work. 

The business design and redesign activities are the same: the end point must be an 
optimal new operating design that is built to change iteratively and rapidly to keep 
up with future change needs. The five basic steps above will need to be performed 
for any level of business design and for each iteration in a design that supports 
continuous improvement. 

Different tools and approaches can be used to help focus iterative designs and 
improve specific problems or quality, but they need to be matched to the need and 
the goal to ensure that the right tool is used in the right way. These approaches 
include Lean, Six Sigma, Lean Six Sigma, Activity Based Costing, SIPOC, Value Stream 
Mapping, Kaizen Events, FMEA, Service Level Agreements (SLA), and so on. Tools 
described as Business Process Management Suites (BPMS) range considerably in 
capability, complexity, and ease of use. When a BPMS is used, we will refer to the 
joint business-BPMS-IT environment as a BPMS-supported BPM environment or 
operation. 

In approaching process design, it is important to know whether you will be dealing 
with a cross-functional end-to-end process or a more specific problem-resolution 
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effort that is really focused on workflow. This distinction will be discussed in several 
places in this chapter, as it is critical in determining scope, approach, level of effort, 
governance, and benefit. 

These topics and other considerations that should be part of a process design are 
provided in the discussion below. 

5.2.1 Process models are not "Business Architecture" models of the 
business 

A common misunderstanding among people involved in business modeling is the 
difference between Process Models and Business Architecture models. Business 
Architects do create models of the business, but the Business Architect’s models are 
at a high level of abstraction and deal with Business Capabilities — the ability to 
perform or deliver a very high-level business function. An example is the ability to 
bring a new product to market. The capability is stated as "the ability of the 
company to bring a new product to market within a one-year time frame." Another 
example, for a pharmaceutical company, is the ability to conduct clinical trials for 
new drugs, following all legal requirements. 

Capability models are thus conceptual and deal with the "whats" in the business. 
Process models, on the other hand, deal with the "hows" of the business and define 
how a deliverable, product, or service is built and delivered. In this way the 
Capability models, when decomposed to low levels of detail, define all the activities 
that a business will need to be capable of doing. Since every activity relates directly 
to a given business capability, these capability models define all the activity needed 
to be effective. They do not however, address effectiveness. Process models focus on 
physical activity and its management. These models look at the way work is actually 
performed. They are thus concerned with efficiency. 

When combined, they allow the designer to crossfoot the design activities to ensure 
that no work is performed that does not relate to the delivery of a needed business 
capability. This ensures effectiveness. These components can then be flowed and 
their management improved. By adding automation, the designer can ensure that 
the design does not include unnecessary work and that the work performed is as 
efficient as possible. 

Part of the reason for the confusion regarding these two model types is that in many 
companies, process models are built by business analysts instead of process 
analysts. The two disciplines look for different things in the business operation. 

Few people except practitioners who are schooled in both Process Architecture and 
Business Architecture understand the relationship noted above, and most people 
wrestle with both the meaning of business capabilities and the definition of process. 
This has caused a blurring of "process" and "capabilities," such that many people 
believe process models are the next level of detail under a business capability 
model. As noted above, this is simply not true. 

Both disciplines try to deliver business improvement, and both have their place in 
doing so. The fact is that these disciplines complement one another: they are not the 
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same and they do not compete. Both are needed in any process- or enterprise-level 
change. But in many companies, this emerging distinction is not yet made and the 
roles of these positions are somewhat muddled, as are the tools that each group 
uses. 

5.2.2 The Starting Point 

The scope of the change or improvement project will determine the nature of the 
BPM project. If it is to be cross-functional and address the entire process, the change 
will be more strategic in nature and require a long-term commitment, as the team 
will need to address work in many different business units. A project at this level is 
both invasive and disruptive, as is characteristic of any large project. Planning and 
control are also very different in a project of this scope. Here, it is worth suggesting 
that once the high-level "As Is” model is created, the project be broken into 
components and redesigned in parts that will be meant to fit back together. This will 
require design and management at two levels to ensure that all components do in 
fact fit together and that they combine to provide a fundamentally new approach to 
performing the process. With change at this level, associated significant benefit must 
be realized in order to undertake this level of effort. 

The second level of BPM change project is related to solving a specific problem or 
accomplishing a specific goal. The scope in these efforts is generally narrow and 
certainly much narrower than a process redesign project. In these projects, change 
is usually focused on workflow. This distinction is critical, and it is a key difference 
in use of terms "process" and "workflow" in this chapter. 

Process design begins by creating an understanding of the way the business works 
today — what is done, where, why and how. This fact-finding is an investigation into 
the documented and undocumented activity of the business operation. While it is 
important to understand the way the business works, it is also important to 
understand the way the business should work — in the opinion of senior 
management. What is wrong and why? Where are the hand-off problems? Where 
are the decision problems? Where are the rules undefined and subject to 
interpretation? In performing this fact-finding, the team will collect and review all 
relevant existing documentation from the business unit, Business Architecture (if 
this group exists in your company), and IT. After review, the team will be in a 
position to list their documentation-related questions and prepare for their 
interviews and workshops with business operations staff. 

Note: Most documentation will be out of date, or at best partially up-to-date. Often no 
one will know for certain what is accurate, and many will fail to relate the dynamic 
nature of the business to the need to keep business and systems documentation up to 
date. Example: We were redesigning a business area in a large company and asked for 
the latest business models. The models we received were dated "2000." When we 
questioned their currency, we were told that they were up to date because the business 
was still doing the same thing. We then interviewed the business area staff and 
updated the models. These were then returned to the group that had given us the ten- 
year-old models. 
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This information provides the foundation for the first look at what may be wrong, 
missing, under-supported or functioning incorrectly. But most importantly, it 
provides the change team, management, and business staff with a clear and agreed- 
upon understanding of how the business really works. It also provides an 
understanding of how management envisions the business unit to function. The 
analysis of the "delta” between the actual and the expected business operation 
provides guidance for the high-level requirements of the change and the new design. 
It also points out where the new design may want to start and what should be given 
a high priority. 

Of course bridging these gaps is fertile ground for finding "low-hanging fruit" 
changes. These are actions, rules, approaches, work, etc., that do not need to be 
performed, are redundant, or are in opposition to management expectations or the 
way management sees the business. 

5.2.3 Defining Data Collection Standards 

In any enterprise or full process level effort, the company will need a significant staff 
of BPM practitioners, along with other disciplines. For the purpose of the CBOK, we 
will focus on BPM and BPM practitioners. Here there will likely be multiple teams, 
and within the teams, multiple pairs of people who perform the interviews or 
workshops. Different people will look at activity, rules, problems, and more. 
Experience has taught us that it is imperative that the information collected be 
consistent across the effort. If it is not, quality will be suspect, important 
information may be missing, and it will be impossible to provide an accurate picture 
of the business. 

Clearly on a smaller scale, but still important, is the need to standardize the 
collection of information at the workflow level or, lower, to the task level. The same 
driver applies at this level as at the process or enterprise level — the need to create a 
clear understanding of the real business operation. 

To do this, formal information-collection standards must be put in place. These deal 
with what information will be collected from whom, the way the information will be 
vetted, the way the information will be stored and organized, the way it will be 
changed, and the way it will be used. 

If the company has process-related modeling, data collection, and other standards, 
they will need to be found and followed. However, few companies have BPM 
information-discovery, modeling, data collection, interviewing and other standards 
to control the approach taken in controlling information about the company's 
operation (other than financial regulatory standards) and even fewer have 
standards dealing with the delivery of basic modeling and information consistency. 
Without these standards, each group of interviewers and each project team will 
collect different information, and each model will follow different modeling 
conventions. Such inconsistency has proven to cause problems in creating an 
enterprise business model and in driving analysis, costing, benefit analysis, 
performance measurement, and design simulation. 
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For teams using a BPMS tool, the models will force the creation of standards — if 
anyone is to ever make sense of the models at any level of detail and be able to 
access the data that is stored in the tool. However, if the use of these tools is not 
governed by standards, the teams may still fail to collect all the needed information 
or to vet it. Even with standards, compliance reviews are important to enforce their 
use and ensure quality. Defining standards for BPMS-supported BPM projects 
begins with the acceptance of use standards provided by many of the vendors. 

These standards are a starting point. They will still need to be modified to support 
the internal business operating standards, the IT standards needed for the BPMS to 
run in the company’s IT technology environment, and for the models to conform to 
company protocols. While these standards are needed to ensure security, access, 
consistency and more, they become critical in a collaborative environment with 
team members and business units located around the globe. 

Where a BPMS is not used, it is important to determine what information will be 
needed for all projects and to make this standard. Here the team will likely use a 
modeling tool, a spreadsheet, a presentation tool, and a word processor. This will 
serve as a core set of information to ensure that a minimum understanding of the 
operation can be constructed. Individual projects will be expected to add project- 
specific information to this standard. This is true for both a BPMS-supported effort 
and a manual effort. 

From an information-collection and storage perspective, the real problem where a 
BPMS is not used involves information organization and change control. Finding 
anything becomes difficult when the project is large enough to require several 
people or multiple teams. The people simply collect too much information to 
organize for easy access. Controlling change over the life of the project is almost 
impossible in these projects and requires the commitment of project resources 
serving as librarians. Of course, this is a luxury that few projects have. 

In defining information-collection standards, it is also important to define the use 
that the models and information will be put to. For example, if the models will be 
used to simulate the current operation and the operations assuming certain 
changes, it is necessary to define the data that will be needed to drive the 
simulation. This is important because it will make certain all needed information to 
define a baseline is collected during the analysis activity. By defining and then 
obtaining this information during the analysis activity, the team will be able 
improve the quality of the analysis while limiting the number of times they will need 
to interview the users. 

For this reason, it is strongly recommended that any BPM project begin with the 
identification of standards that must be used and the creation of project-specific 
standards that are needed to provide consistency among the products produced by 
different team members. 

In addition, many projects suffer from terminology disconnects. BPM and BPMS 
acronyms and terminology differ from company to company and from project team 
to project team within a company. Part of the reason is that there are few commonly 


168 


Copyright ABPMP International 



Chapter 5. Process Design 


accepted definitions for most things related to BPM and business transformation. 
But, as much trouble as this situation causes, the use of internal terms between 
business units and differing definitions of these terms causes much larger problems. 
Experience has proven that even simple "everyone knows that" terminology must 
be defined so it can be used consistently between departments and between the 
business and BPM teams. These definitions must be agreed upon by the business 
managers, IT, and collaborative partners so that everyone can stay in sync. But, this 
also represents a significant cultural and political problem. Whose definition will be 
considered right and thus generally used? The fact is, creating this dictionary is not 
a simple task. 

However, until all terminology and acronym usage has been agreed upon, 
information-collection standards will provide limited success in allowing everyone 
to understand how the company operates and how it can be improved. 

5.2.4 Managing Process Design 

This section of the discussion is not concerned with project management. With 
consideration for the unique BPM and BPMS tasks, project planning and 
management is basically the same in BPM projects as it is in projects using other 
disciplines. Although the tasks in a Business Process Management Suite (automated 
modeling and application generation tool)-supported BPM project are somewhat 
unique, the normal project management discipline will provide adequate control 
and management. 

Because there are few formal BPM approaches today in most companies, project 
teams are largely allowed to define the approach that will be used in their project. 
The result is that in most companies, each BPM project is approached and 
performed somewhat differently than any others. As expected, each of these 
approaches will have strengths and weaknesses when viewed in the context of the 
company, its culture, and its IT support. To benefit from this experience, companies 
should review past BPM projects and define their approaches for use as lessons 
learned. This will help create a best practices approach within the company and 
define a company-specific methodology that will ensure accuracy, quality and 
success. For those who wish to take a more strategic approach, this also helps 
ensure that all relevant information has been collected not only for the project, but 
also to meld with information from other projects to form enterprise, or end-to-end, 
process models. 

Any approach taken should thus be standardized and presented to the team as the 
company standard that will be used and audited in moving forward, first into the 
data-collection and analysis activity and then throughout the remaining effort. As 
noted, any approach and method, especially when new to the company and/or team, 
should be monitored to ensure that it is being followed. This control may be 
provided by a project management office/group or by a BPM Center of Excellence. If 
this is done, everyone’s work will "fit" together and everyone will be able to 
understand any of the models or information. 
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Further, to avoid overhead, the method followed should be customizable to each 
project and reflect the complexity, scope, importance, and benefit of the project. 

This method will then be used to guide project planning and be merged with the 
company’s approach to project management, in order to provide a focused project 
plan. 

Clearly, the need for consistency of approach and information-collection requires 
some form of management action in advance of activity. This is the foundation for 
managing the activity that will be needed to build the "As Is” and "To Be" process 
designs and maximize the impact and value of each activity performed in this 
development. 

5.3 Process Discovery -The "As Is" or "current state" 

As mentioned, any change must start with an understanding of the current situation, 
operation, constraints, politics, and more. This cannot be omitted. You cannot 
simply start over as if the company and its operation have no history. It is also 
important to note that no company operates in a vacuum. Any company is a complex 
network of customers, suppliers, collaborative partners, workers, rules, financial 
history, market reputation and more. Together, these form the company. Any 
change cannot ignore them. This is critical in designing an implementable change or 
change roadmap that will guide the evolution of the company. 

5.3.1 Creating a firm foundation for change 

Understanding this history and the current operation is the foundation for any new 
design — regardless of its scope of impact. The new design itself must solve existing 
problems and allow the business to take advantage of known and discovered 
opportunities. Attempts to skip the initial analysis and business redesign activity 
deliver mixed results — from solutions that just don’t work the way people thought 
they would, to solutions that actually make things worse. So, at this point, we will 
accept that this information is needed and understand that it is critical. 

To help organize this information and make it relevant (provide a context for 
understanding its meaning and impact), it is recommended that any improvement 
adopt a process perspective. This perspective includes the potential processes that 
are in scope, the business units the process (or processes) flows through, the impact 
of its (or their) activities on each business unit it flows through, the problems 
associated with the process(es), and the potential impact of given solution options. 

Experience has proven that any new operational design must consider the history of 
the company, the problems and limitations that box any improvement, the 
budgetary realities, the culture and its ability to absorb change, the interactions 
between business units and processes, the relationship between the company and 
its business partners and its approach to collaboration and partnering with 
suppliers and customers. These factors and more are vital in designing any 
improvement solution. 
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The identification and definition of these factors, when added to the models of the 
process and the workflows in the business units, forms a knowledge foundation for 
change and work optimization. The result of this knowledge foundation is the 
creation of a very different perspective on the business’s operation. The end-to-end 
perspective that a process view provides allows management to understand the 
scope and impact of problems and where they start. This is key in redesigning 
problems out of existence or, if they are related to things that cannot be changed (a 
whole new computer infrastructure or legislative mandate), building a type of 
operational shell around the problems, which effectively controls them. 

With this foundation, it will be possible to move to an operation model that is based 
on learning and continuous improvement. The framework that the process and 
workflow models provide allows performance engineers to utilize disciplines like 
Six Sigma and Lean to define improvement opportunities, and techniques like 
performance measurement and monitoring to identify improvement objectives. 

This process-centric perspective is equally important when addressing problem 
resolution projects using BPM. The needs and benefits are similar and essentially 
are the same as the workflow view in the process-centric decomposition hierarchy. 

5.3.2 Managing Process Information 

As the information is collected and analyzed, the team will need to organize and 
consolidate a vast amount of data. Today, popular modeling tools that include Visio, 
or more advanced modelers like Casewise and the tools included in Business 
Process Modeling Suites, are used to provide a common repository for this 
information. While supporting its translation into a flow-model format, these tools 
offer a graphical representation of the information at various levels of detail 
(process decomposition) — showing subprocesses and, at lower levels of detail, 
activities and even tasks. While these modeling tools allow the modeler to show the 
work and workflow in an easily understood manner, they are limited in their ability 
to help design the new business. 

More advanced full Business Process Modeling Suites (BPMS) provide modeling, 
rules management, workflow management, performance measurement, application 
generation and data handling (through Services Oriented Architecture tools). These 
tools are extremely flexible and offer a significant group of advanced features that 
pure modeling tools cannot provide. The team, the data that is collected, the way the 
data is handled and the level of detail that is captured will, to a large degree, be 
dependent on the tool that is used to support the team. This will also determine the 
amount of data that can be dealt with and the way the information can be stored, 
retrieved, and consumed. 

But regardless of the tool used to support modeling and information collection and 
analysis, the design team will need to organize the information into easily 
understood groups of related documents and models — starting with the way the 
business works today. This is the "As Is" model and its supporting information. A 
BPM project team should consider the tools that will be available and their 
capabilities when they formulate their project strategy and plan. As the information 
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is being collected and the models are being built, the team will need to consider the 
way the models will be structured. It is very easy to look at virtually the entire 
business as a single large process. It is also easy make models so complex that no 
one can possibly understand them. While modeling standards will help, as will the 
use of a standard set of modeling symbols such as BPMN (business process 
modeling notation), the structure and architecture of the model hierarchy and the 
models themselves are critical to their use, the ability of the team to confirm them 
with the business users, and then to leverage them in defining a new design. 

Example: Many companies and departments within companies have used Visio to build 
process and workflow models in the past. Because past versions of this tool were not 
based on BPMN, any symbols could be used — people, machine, and other graphic 
symbols were commonly used. The result is that the symbols were used inconsistently, 
and without significant notation on the diagram, they are difficult to interpret. When 
the team that created the model is no longer part of the company, using the models 
becomes a problem. 

The same need for consistency is seen in the information that is collected to 
describe the model and its activities in detail. This information may include timing, 
volume, decision probability, error rates, staffing level, rules, and more. 

5.3.3 Model levels 

Process information discovery, as discussed above, will have discovered information 
at various levels of detail. These levels of detail will need to be sorted out and the 
information assigned to different levels in a process model hierarchy. This hierarchy 
will begin at a high level with the entire process, and then be broken down or 
decomposed into lower levels of detail until the activities in a process are defined. In 
this decomposition of the process models, the process is divided into subprocesses 
and then functions. The functions are then related to the business operation where 
they are performed, and combined with other subprocess work to form the 
activities in the business unit. These are then flowed to represent the way work is 
performed in the business unit. 

It is suggested that the information be assigned to a given level of detail as it is 
collected. This assignment can be changed as the team learns more. The information 
at any level in the hierarchy should be clearly aligned to information at a higher 
level in the hierarchy, and thus represent additional detail as one goes lower in the 
hierarchy. This will allow the team to identify missing information or information 
that needs to be questioned. 

The following diagram (Figure 42) is an example of a process hierarchy. Different 
firms may use fewer or more levels and may label them differently than in this 
example. The important fact is that the team will need a way to organize the 
information collected and the models that are built, if there is to be any hope of 
controlling the information and its quality. 
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Level 1: Process 


Shows Sub Processes and their 
relationship to one another 


Shows the Business functions in a 

Level 2: Sub Process Sub Process and their order of 

execution 

Shows the Business Units that 

Level 3: Business Function perform the work in a Business 

Function and the way work flows 
between them 

Shows the activities that are 

Level 4: Workflow in a Business Unit performed in the Business Unit and 

their order of execution 

Shows the real work that is 

Level 5: Tasks and Scenarios performed and how it clumps into 

like work groups or scenarios 


Figure 42. Process Hierarchy: Levels of Detail in Process Modeling 

Note: The number of levels and their names will vary by the methods and naming 
conventions used in different companies. The important fact is that the process must 
be broken into a low enough level to understand the activities that are taking place 
and how they fit together to produce the business unit's end products. The levels in the 
diagram above are thus a sample of how a company might look at defining levels of 
detail in the process modeling standards. 

The number and name of the levels in both the current "As Is" and the future "To Be" 
models should be directed by formal business modeling standards. In the past, these 
standards could be independent of any external modeling standard or tool, but that 
is changing. Care must now be taken to align internal modeling standards with the 
tools that are used and their capabilities and limitation. For example, while it is not 
the only modeling standard, BPMN2.0 is becoming a major standard for BPMS 
vendors, and internal modeling standards may well need to conform to BPMN. 
However, a good rule of thumb in looking at modeling standards is that they address 
at least the following levels in some form: 

1. The highest level model is a process model that provides a full end-to-end, 
high-level view of the process. This model can show subprocesses and may 
show high-level problems and application systems. 

2. Subprocess models are the next level and divide the work into business 
functions and then align the business functions by business unit. 

3. Workflow within a business unit is a third level, and it identifies the activities 
that are performed. This level model can also be used to show the 
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relationship between activities, with activities from other functions and 
subprocesses that are also being performed in the business unit. 

4. At the fourth level of detail (scenarios) it will be easy to understand how 
work that is performed in the business unit is driven by events or timing or 
data values. By rolling the task up to activities, then up to workflow and then 
to subprocesses, it is easy to see how all work fits into processes and how it 
plays a role in producing the end product of the process. 

But this fourth level of detail provides only a basic understanding of the detail in the 
business operation. It is often not a sufficient level of detail to resolve problems, 
reduce cost, or support automation. For these actions, it is necessary to take the 
workflow to a greater level of detail, the task level. 

At this (fifth) level, the business and BPMS designers will usually have enough detail 
to tie rules to specific actions. The use of data will now be at a low enough level of 
detail to design application screens and reports, and define edits and low-level 
decisions. This level is used to generate BPMS applications that manage work and 
automate manual "transaction"-level data entry and use. 

This is the level where the analyst identifies the tasks that are performed to deliver 
the output or outcome of a single activity. For example, when an insurance 
company’s policyholder into the system, this level of the model will define the tasks 
that must be performed to enter the new policyholder. Another example at this 
level, in manufacturing, would be build-to-order, after a customer places an order 
with a sales person. The process analyst must define all the tasks needed to identify 
the "customized" product, and — assuming a build from common parts — to identify 
the parts, define the options, cut the build order, get the parts, and then construct it. 

And yes, there are still lower levels of detail that may be needed. The key is to take 
the map to the level that you need to support what you are doing AND what 
someone in the next phase will need to do. This may be to build an application using 
traditional languages, generate a BPMS application, build interfaces to legacy 
applications, build web applications to interact with customers, and more. The key 
is that the requirements for any of these follow-on activities will need to be 
considered and the detail needed to drive their completion must be reached in the 
models. 

This presumes that (at least) at the project level, the project manager will begin the 
project by defining the deliverables and then setting internal standards for data 
collection, interviews, models, etc. Of course, if company standards exist to address 
this issue of consistency, they will need to be followed. 

See chapter 3, Process Modeling, for a more detailed look at the way process models 
are constructed. 

5.3.4 Process and Workflow Discovery 

Any change must start with a firm understanding of the way the business operates 
today and its problems and challenges. This foundation, however, is a constantly 
changing picture as the company adjusts to business reality and competitive 


174 


Copyright ABPMP International 


Chapter 5. Process Design 


pressures. For this reason, the way the business operated six months ago is 
probably not exactly the way it works today. Old models and old information from 
IT, Business Architecture, or Process Architecture are almost always out of date and 
can cause harm to the new design if used. For this reason it is necessary to always 
begin with a revalidation of existing information and where needed, an extension of 
the information and models to show the operation as it functions today. 

5.3.5 The way the operation really works 

The question many ask is "why do I need to be concerned with "As Is" models? I am 
changing the company, why not just focus on the future state?" The simple answer is 
that you must understand the operation before you can change it. You cannot just 
produce a new conceptual future-state model and expect to implement it without 
building an ability to move from the present to the future. 

Part of the reason for this need to understand the current business operation comes 
from the fact that few businesses offer true "greenfield" design opportunities. Most 
of the time, the design team will not have the luxury of dealing with either the entire 
business or a totally new department and must consider the current business, its 
limitations, its problems, costs, and its culture. To limit the design options even 
further, the team often faces the requirement to consider changes to the business 
without the benefit of being able to affect the business operation components 
preceding or following the part of the business being changed, in the larger process 
context. 

However, when a project does provide an opportunity to work on a totally new 
business operation or an entire end-to-end process, the team may proceed without 
many of the concerns that limit the teams changing a business operation. Here, the 
team must still consider how the new operation will fit into the business and how it 
will be supported by Information technology (IT). So, even in greenfield design 
opportunities, the design cannot be totally without constraints. 

For these reasons, it is not possible to simply view the change as if you were able to 
start over, with no corporate history, no culture to deal with, no legacy IT 
limitations, no cost limitations and no consideration for the parts of the business 
that simply are not part of the design project’s scope. Given this reality, it is critical 
that the design team understand the current operation — at both high and low levels 
of detail. 

In addition, few people really know how the work in a whole process or business 
unit is actually performed. Managers obviously have a good idea, but given that 
many rules are created as needed to address unautomated "whitespace" work and 
that most rules are interpretive, no one can guarantee that any activity will be 
performed the same way twice. This is a reason outcome consistency is a problem in 
many companies. 

Note: Creating a complete understanding of the business can have an immediate 
benefit from standardizing rules and parts of the workflow. It can also help 
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management make immediate decisions that can improve the operation before the 
workflow analysis begins. 

Thus, the design of any new ("To Be”) business model must take into account the 
realities of the current business operation and the problems and opportunities that 
exist. It must also consider the current business rules, timing requirements, the 
need to balance the workload among the staff, the realities of corporate policies and 
standards, reporting requirements, audit requirements, and more. These factors are 
identified and defined in the analysis of the current ("As Is”) business operation 
through the collection and review of operational information. 

This analysis of the "As Is" business models and information is the first point where 
creativity and business acumen come into play. As the analysts are reviewing the 
information, they will have an opportunity to notice inconsistencies, activities that 
just don’t make sense, and opportunities for improvement. This is the basis for 
recommended change and design improvements. These improvements will 
generally fall into two categories — candidates for fast, inexpensive, immediate 
improvements ("low-hanging fruit”) and longer-term, more invasive, more 
disruptive, and more costly improvements. 

Existing "current state” or "As Is" Process Models should have been updated, if they 
exist in the company, for the business area(s) that are in scope during the 
information discovery and modeling activity. If they don’t exist, they will have been 
created during this discovery activity. These models thus provide a foundation for 
the analysis of the current operation. But that is the beginning of its use. 

See chapter 3, Process Modeling, for details on creating process models at any level 
of detail in the modeling hierarchy. 

It is recommended that the project team also view this current information from a 
strategic perspective. The reason is that information collection is generally project- 
focused; it is often not meant to have a life beyond the project, or it simply cannot be 
maintained and becomes out of date. Using a BPM approach and supporting 
Business Process Management Suite (BPMS) tools, this situation changes. The 
information from each project can be added to a common Enterprise Database with 
the eventual goal of providing a complete process-centric view of the company and 
its operations — the way it really works, not simply the way some think it works. 

Project-level content should be used to support the eventual creation of the 
Enterprise Business Model. Doing so removes the overhead of creating this whole 
model as a project in itself. To support the evolving enterprise modeling effort, it is 
recommended that the business process models include the following supporting 
information: 

• Processes showing sub-processes and their interaction 

• Subprocess operations showing business functions/scenarios and the 
business units that perform them 
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• Workflow within a business unit showing activities that are performed — this 
may be broken into lower-level models to show the tasks that are performed 
within activities. 

Note: these levels of model decomposition form the process modeling hierarchy. 

• Problems and their impact aligned to the one or more sub-processes, 
business functions, activities or tasks they affect 

• Opportunities for improvement and the expected benefits aligned to the part 
of the business they affect 

• Metrics (staff, volumes, error rates) aligned to the point in the business they 
measure 

• IT applications that are used and where they are used in the business 

• Basic functionality that each application system provides 

• Data that is collected, where it is stored, how it is edited, and how it is used 

• Rules that control the work — both documented and undocumented 

• Decision processes with the probability of each exit from a decision 

• Standards for quality/cycle time / efficiency etc., 

• Internal audit policy and any requirements 

• Performance measurement requirements 

Note: this is a partial list of the information that should be collected as part of creating 
the “As Is" process and workflow business models. It is also the core information that 
should be considered in building an Enterprise Business Model. 

The key point here is that with forethought as to the eventual use of this 
information, it will be possible to use it both in creating the solution that is the 
target of the project and in the incremental construction of a process-centric 
enterprise business model. 

5.4 Strategic Business Change 

Changes in business strategy and in the Business and IT capabilities that will need to 
change to support the new strategy are key drivers of broad-based business 
operation changes. These changes require the same type of discovery activity, but 
working together with the Business Architects and Process Architects to determine 
what processes and what parts of processes need to change, and how. This 
procedure will then be followed from subprocesses to business function to business 
unit to help define the scope of the project. 

Once the Business and Process Architects have isolated the broad areas that will 
change, they will need to work with the Enterprise Architects to determine the 
impact on the IT infrastructure, the supporting applications, the company data and 
technology governance. Together, these perspectives will form a complete picture of 
the needed changes. This in turn, allows these architects to identify the initiatives 
and projects needed to deliver the strategy and support its goals. These initiatives 
and projects can now be related to specific business units through process changes 
and the requirements that each change must support. 
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In strategy-driven change, it is critical that all changes can be traced to directly 
supporting the delivery of a given part of the business strategy. The analysis of any 
response to a strategic change must thus include alignment to strategic goals at all 
levels of detail (decomposition model levels). This is supported through the 
relationships between strategy and initiatives, and between initiatives and projects. 
At the project level, the work becomes focused on the changes needed in a business 
unit and its workflows. 

Formally defining the relationships between change projects allows executive 
management to look at project funding differently and facilitates a type of program 
management that coordinates the activity between projects and between initiatives 
to ensure that the goals of any strategy are met. 

5.5 Process Analysis— Gaining an understanding of the business 

Question everything. Nothing can be exempt in the quest for improvement. 

The truth should not be hidden in this analysis — although politics will play its part. 
Where there are political boundaries, the project will need to be adjusted to work 
with the restrictions. 

The purpose of the analysis is to identify how the business can change, the 
restrictions on it, and focus points in the change. The design team will use this 
information to focus on initial improvement considerations or on strategic changes. 

Once the "As Is" information collection and process/workflow modeling is 
underway, analysis activity can begin. Although there is no one best way to analyze 
this information, it is suggested that a review of incoming information be used to 
create a type of framework that allows the team to align information and business 
activity. Care should be taken in this alignment to look for obvious opportunities to 
improve the operation, such as redundant activity, activity that is uncontrolled, 
activity that just doesn’t make sense, activity that provides little or no real value to 
the process or to the customer, and unnecessary hand-offs to other departments or 
holds for approval. These should be analyzed and evaluated. It is also suggested that 
the team meet daily to discuss what it is discovering. This will allow the teams to 
more easily recognize patterns and redundant activity. 

It is also appropriate to look at the deliverables of a business unit, business function, 
or subprocess. All work must contribute to one or more of these deliverables. If it 
doesn’t, it must be reviewed and analyzed for value. 

All problems must also be clearly identified and defined. They must then be linked 
to the business activities and business functions they affect: the impact should be 
noted and the impact assessment signed off on by a business manager. A "Problem 
Matrix" should be created to show the results of problem analysis (see Figure 43). 
This matrix should show the problem and the places it impacts. The place on the 
matrix where the problem and the place impacted come together should show the 
specific impact. This will have a wide variety of uses in the new design. 
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Figure 43. Problem Matrix 


In addition to problems, all business improvement opportunities identified during 
interviews, documentation review, or model review should be noted along with the 
probable impact of their implementation. This relationship should be shown in an 
Opportunity Matrix with the opportunities along one axis and the business unit or 
group that will be affected along the other axis (see Figure 44). The intersection will 
show the impact of the change on the business. 
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Figure 44. Opportunity Matrix 
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The team should also look at the flow and the way it is managed. Consideration 
should be given to such improvements as work listing, workflow monitoring and 
management, standard tracking with time-based warnings, automated work 
assignment, and workload-shifting to better control workload balancing. 

While these and other business operation analyses are under way, it is also 
appropriate to look into IT support and determine the limitations of IT's capacity to 
support the current and possible future business operation. The realities of this 
review will either limit the new business design or open it to a wide range of 
support possibilities. 

In this analysis, two key questions must be foremost in the team’s minds. First, how 
can work be made more efficient and cost-reduced? Second, how can the operation 
be made more flexible and ready to change quickly? Together these support the 
delivery of sustained optimization through continuous improvement. 

See chapter 4, "Process Analysis," for a more detailed discussion of the concepts 
used in BPM-based process analysis. 

5.6 Process and Work Flow Design— Creating the "To Be" Design 
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Figure 45. Workflow Design and Application Generation 


At this point, the discovery activity will have created the "As Is" business models and 
they will have been analyzed for ideas on how to improve the operation. Limitations 
and requirements will also have been formally defined for use in any change. 
Following a roadmap similar to that in Figure 45, activity now moves to the redesign 
of the business operation. This redesign is where creativity is critical — people must 
think "outside the box." 

Process modeling tools that best fit the organization and best support the desired 
goal in the process design should have been selected either before project start or 
during the project’s discovery and analysis activities. However, a modeling tool may 
have been used in the discovery and analysis activities that will not allow solution 
design, simulation, or application generation. In this case, the company may choose 
to license a full BPMS tool to support application generation and facilitate the 
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interfacing with legacy applications and data. It may also decide to build the 
application support and interfaces in a more traditional language and use the 
current modeling tool to design the "To Be” business model. 

During the analysis stage, possible changes to the processes, subprocesses, business 
functions, and (within business units) activities in the part of the organization that is 
within scope are listed, weighted, and prioritized. This reveals a clear picture of the 
weaknesses of the current process or processes and helps decide what will be 
redesigned and in what order. Once the business areas to be changed are selected, 
the degree of the change can be assessed to make either incremental or large-scale 
systemic changes. Sometimes, making frequent small changes can have an equally 
significant effect on process performance as large radical changes, provided there is 
a clear and accepted vision of the future state. 

In looking at redesigning the operation, the team should understand that the "As Is” 
model imposes a type of modularity on the operation. Each activity operates 
independently with links to other activities through inputs and outputs. Within the 
activity, the work is controlled by both management oversight and business rules. 
Support is provided by IT in the form of applications and data delivery, 
manipulation, and storage. All can be viewed as a single integrated module or, in 
SOA terms, as a business service. In this view, the operation is a flexible framework 
of interconnected services, each producing some outcome or deliverable component 
of a larger product. This is important because this modularity allows the team to 
identify the parts of the operation that provide the greatest immediate and then 
long-term benefit, and to address them separately. 

In this approach, a business workflow can be considered to be a module that is 
made of separate, smaller, component modules. The key is that at any level, each 
module is a completely functioning part of the business. It produces something that 
is consumed by another module. These modules are building blocks that can be 
combined in any order needed to produce a bigger product or service. In this way all 
are interchangeable and all are reusable. 

This is made possible by the way the work activity module is handled. The integrity 
of the module is maintained by ensuring that the input and output of the module 
remain constant — hopefully with improved output. So, given that the input and 
output requirements do not change, the team can do whatever is needed within this 
module. However, if an output is changed, the change will ripple and the extent of 
both obvious and more hidden impacts must be considered. 

Note: Any change to an output at any level in the Process Hierarchy can have hidden 
impacts. It is possible to have no impact on the next activity in the workflow, yet 
seriously impair an activity two or three modules downstream in the workflow — 
including activities outside the scope of the project. It is also very possible to improve a 
given activity or business operation and harm quality downstream of the change. For 
this reason, the team should both understand the downstream modules and work with 
business and IT managers to make certain that no harm is done in a change. 
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By taking this approach, it is possible to address the business modules or services in 
the order of their greatest impact on achieving the goals of the project. By using the 
business models for context, the team can look at the benefit associated with any 
module. It is thus possible for the team to focus on the most significant 
improvements first. This is possible because of the relationship between the 
business modules. As modules are improved, they are linked to those they touch in 
the same way they were before they were changed. As far as the impacted modules 
are concerned, nothing has changed — they still see the same output and they still 
deliver the same input to the next module. In this way, change is isolated to 
individual building blocks and all building blocks remain linked to produce the 
outcome. This approach must, however, make allowances for the complete 
elimination of modules or groups of modules when they become automated or 
unnecessary. In these cases the output/input links will be broken and will have to be 
rebuilt. 

The technical approach to support the design, construction, and implementation of 
the business improvement will need to be understood by the business design team. 
Likewise, the business transformation approach will need to be understood by the 
technology team. If the process design will be supported by application generation 
through a BPMS, the constraints and options will be very different from a change 
that is supported by .net or even legacy COBOL-based application systems. Because 
these options and constraints will have an impact on the new business and IT 
support design, they must be identified and defined at the beginning of the design 
process. 

Actual design will take place at all levels of the Process Hierarchy. All must be 
aligned in any change and all must be used when downstream activity is considered. 

Although a team’s methodology when designing a new process will vary, certain key 
activities should take place during the design stage of process management. Most 
commonly, these key activities are 

• Designing the new process at all appropriate levels of detail (see Process 
Hierarchy) 

• Defining activities within the new process and identifying workflow and 
dependencies 

• Defining business operating scenarios and modularizing around these 
scenarios 

• Defining all data needs 

• Defining rules that control the activities 

• Defining handoffs of process between functional groups 

• Defining customer value from the change and tying it to success 
measurement 

• Defining desired metrics in the new process 

• Defining and designing business and performance reporting 

• Gap(s) in and comparisons to existing analysis 

• Creating business and technical system change specifications/requirements 
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• Creating the physical design 

• IT infrastructure analysis and design 

• Model simulation, testing, and acceptance 

• Generating or building supporting applications 

• Designing and building interfaces to legacy applications and data 

• Testing all business activities with application support, legacy interfaces, and 
rules 

• Creating and executing an implementation plan. 

It is important to note that although these key activities listed above appear in a 
logical order, they do not necessarily occur in that order and many of the activities 
will occur simultaneously. In addition, this is a partial list that is not intended to 
represent a method or to conflict with any internal company method, steps, or 
activities. Rather, it is meant to serve as a list of activities that should be considered 
within the context of the project, the company methodology, company standards, 
and the needs of the project for control and management. 

5.6.1 Evolutive Management: Using Change to Control Evolution in the 
Business 

Two basic approaches can be taken in creating the new design. The first is to create 
a specific improvement that is expected to be implemented in its entirety at one 
time. The second approach is to create a future state that is optimal, but not (yet) 
practical. Maybe it will cost too much, be too disruptive, or require an infeasible 
change to technology, and the list of reasons goes on and on. But, the bottom line is 
that the design is a good eventual target, and it will define a direction for change. 

In this case, one or several interim "phase" designs moving in the direction of the 
"optimal” state will be made. Each of these designs will solve a major issue or 
deliver a significant improvement. And each phase will build on the foundation of 
the ones that have been built and deployed before it. In this way the company will 
evolve along a planned path. 

However, it should be realized that the "eventual" end-state target design will never 
be reached. The reason is that this evolution approach, called "Evolutive 
Management" (created by Dan Morris, Joel Brandon and Stephano Sommadosi, and 
introduced in Brandon and Morris’s Just Don't Do It: Challenging Assumptions in 
Business (McGraw-Hill, 1988) continually looks to the future, and the end state 
design is adjusted to take advantage of emerging concepts, technology 
improvements, production tooling innovation, and so on. It is also adjusted to 
consider competitive requirements, business opportunities, the changing impact of 
globalization, and more. Given the constant changing of the end-state target, the 
path and the "phases" along that path constantly evolve. This allows the company to 
constantly control the direction of its change while understanding both the direction 
and why it has been chosen. It also requires a corporate commitment to controlling 
the way the business evolves and adopting the Evolutive Management Approach — 
or some version of it. 
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Each of the phases along the path of this evolution will be approached in the same 
way — as a specific improvement type of change. 

5.6.2 Designing the New Process 

Companies function through their processes. Processes operate as directed by 
business rules. Any company’s ability to operate effectively is thus a direct result of 
good processes and rules. But, today an additional element must be thrown into this 
mix. That is the ability to absorb and adjust to change quickly. Top competing 
companies have control over this mix and are able to leverage all elements in a type 
of fluid constantly changing approach to their operations. 

Many companies have parts of this mix in place and under control. Few, however, 
really understand their end-to-end processes or how to optimize both at the process 
level (cross-organization) and at the workflow level (within an organization unit). 
Fewer still have an ability to support rapid change or to control the majority of 
change taking place in the company. Part of the reason for this is that mid-size and 
large companies must formally move at the pace that their legacy IT applications 
and their IT environment can change. And, most IT Departments are inundated by 
requests for application changes and cannot keep up. 

That is the formal reality, but not the operational reality. Only a small part of the 
change in any company is large-scale enough to be noticed or planned. This level of 
change is not funded and it is not tied to formal projects. It cannot be put off and it 
cannot be tracked. The fact is that all companies change constantly: most change 
occurs at a low level and is not well controlled. This is "under the radar" change, 
whose pace in business operations far outstrips the ability of IT to support it or the 
company to manage it, because it is constant and just happens as people find ways 
to get their work done. Rules also change in this underground of constant turmoil in 
companies, and much of this change is needed to interpret the intent or application 
of the rule. This is the cause of business-operational "white space" work — manual 
work that is needed because of automation limitations and speed of change in most 
operations. 

But many of these traditional problems limiting companies’ ability to optimize their 
operations can now be reduced or eliminated by the use of a Business Process 
Management Suite of enabling tools. Key among them are process modeling, rules 
management, application generation, data access control (SOA) and advanced 
performance monitoring and measurement tools. The greatest benefit of using a 
BPMS is to support very rapid change. As discussed in chapter 10, "BPM 
Technology," a BPMS forms a new, integrated business- and technology-operating 
environment. The management of activity is supported, and in some ways 
controlled, by the BPMS and the applications it generates from models, rules, and 
data definitions. A change to any of the models, rules, or data definitions regenerates 
the applications. This allows very rapid prototyping in simulation to ensure that the 
new version operates as needed, and then supports the movement of the application 
into production by setting a software switch. The bottom line is that in a BPMS- 
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supported BPM environment, change can now keep pace with need — at any level in 
the process hierarchy (see Figure 42). 

As a result of the availability of these tools, there are now many ways to approach 
designing the new process. These range from using simple white boards (or brown 
paper) in a manual design, to simple tool-supported modeling, through 
sophisticated software modeling tools that allow the storage and retrieval of 
process information. The use of these tools, whether they are sophisticated or 
simple, manually-created paper models, is supported by a variety of information- 
gathering activities (brain-storming, story creation, etc.) that facilitate the creation 
of the business model. 

A complete discussion of the tools, activities, and methodologies used to model 
processes is beyond the scope of the CBOK®. All of the tools or methods used have 
their various strengths and weaknesses. The correct tool, methodology, and activity 
to define the process depends on the project goal, the culture of the organization, 
the possible need to generate applications, and the current technology 
infrastructure. 

The importance of process-modeling support through an automated tool, however, 
can be found in the discipline it enforces on the project team and in the organization 
of information. Today, vast amounts of information will be collected in any 
improvement project. Organizing this information is a challenge. Forcing the teams 
to collect the right information has been a problem. Remembering the information 
and then using it has been an even bigger problem. BPM modeling tools usually have 
a solid database underlying the modeler and offer both model/information 
organization and advanced information access. 

5.6.2. 1 "To Be" Process Design 

Process-level change should be considered as the first step in change design. Will 
any of the high-level process components (subprocesses) be eliminated or new ones 
added? This level of change is critical in either adding or deleting large areas of 
work. 

The same is true at each level in the Process Hierarchy (Figure 42) because any 
change at a higher level affects all the levels below it by defining the type of change 
and thus the impact. But all change will eventually be designed and implemented at 
the business unit workflow level and through the tasks scenarios within the 
workflows. It is thus important that all levels in the Process Hierarchy be considered 
in any new design. 

The actual process redesign will be based on the idea that the status quo should be 
challenged and that processes should be improved. As noted, this actually applies to 
all levels in the process hierarchy. In this approach, no part of the operation should 
be above question. Everything must be looked at and reviewed for opportunities to 
reduce effort, improve quality, reduce cost and eliminate problems. Problems 
identified during the discovery activity will now be used to focus activity onto the 
work, decisions, handoff, and flow changes that contribute to the problem — and to 
eliminate problems by designing the root causes out of existence. Issues with 
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quality, staffing levels, training, and more must also be factored into the new design 
and removed or mitigated, but the first consideration should be problem 
elimination. This alone will provide significant benefits, but it is only the start of a 
redesign. 
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Figure 46. Where Process Design Fits In 


As the new design is considered, it is critical to involve as many people as possible 
from the different functions that interact with the process, thus utilizing the breadth 
of experience and knowledge of those closest to the process. This ensures that the 
process truly reflects what the organization can accomplish. It also drives out fear 
and engages the staff to promote acceptance of the change. 

Starting with the "As Is” design (see Figure 47), the team should ask at least the 
following questions of every activity. These questions support the basic set of 
analysis and design questions of Who, What, When, Why, Where and How. The basic 
requirement here however, is to look at these questions from the perspective of how 
each of the answers to these questions can be used to improve the business 
operation and the value it provides to the customer. 

• What is the purpose of this process, subprocess, workflow or activity? 

• Is it redundant or similar to another one that is being performed? 

• What are the problems, quality and governance issues, and why are they 
occurring? 

• Why is this step necessary? 

• What is its purpose? 
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• Where should it be done? 

• When should it be done? 

• Who is best qualified to do it? 

• Is it properly supported by automation? 

• What are its major problems? 

• How can the problems be eliminated? 

• How can the operation be made as effective as possible (only do what needs 
to be done)? 

• How can the operation be made as efficient as possible (eliminate unneeded 
activity)? 

• How can noted waste be removed? 

• Are there standards that must be hit? 

• How can we monitor the activity and ensure that performance targets are 
hit? 

• What are the factors limiting change(s) to the process, subprocess, workflow, 
activity, or scenario? 

Note: This is a partial list of the questions that need to be asked. These questions serve 
only as an example of the types of things that the team must consider in designing a 
new operational change. 

In the approach taken to redesign the business, the team must be open to creative 
ideas and they must be visionary in their thinking about how the business could 
operate. Every activity that is performed must have a specific business reason and it 
must contribute directly to the delivery of a service, outcome, or product. If it does 
not, its value must be critically questioned and it should be either changed or 
eliminated. Activities must provide measureable or definable value to remain as a 
part of the operation. However, in defining value, the team should not limit 
themselves to looking at direct customer value. Financial value to the company, staff 
retention, improved ability to compete and a variety of other value categories are 
also valid in this questioning and in the new design. Value categories, however, 
should be definable (and defined), validated, rated, and approved. All work should 
then fit into one of these value categories. 

Once work has been determined to provide value, it will be considered to contribute 
to the effective operation of the business — doing the right things. This should 
eliminate all work that is no longer necessary, but it will not address efficiency in 
any way. 

This initial adjustment is needed to provide a new foundation model of the business. 
If a BPMS tool is being used, this will now start a new design model. 

This activity evaluation and deletion should be done using the Business Modeling or 
BPMS tool that the "As Is” model is in. Here, the team should start by making a copy 
of the original "As Is” model and then deleting all unneeded work. Of course this 
elimination of unnecessary work will cause holes in the "As Is” model of the work, 
but this revision can now be considered the starting point for the new model design. 
Several copies of this new "As Is” model should be made and assigned to sub-teams. 
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Each team and sub-team will thus have their own unique version, and can then be 
asked to creatively look for and model activity, and thus workflow-level 
improvements. This will allow them to think outside the box. The goal here is 
problem elimination and operational efficiency. Through trial and error, the new 
designs can be created and tested. A new composite model can be created by 
identifying and using the best-of-breed components of the various team versions. 
This model will then be optimized by running it through the simulation tool and 
comparing it against the baseline or "As Is" model. 
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Figure 47. Designing a New Process 


Once this model is created, the improvement must still be viewed from the 
perspective of upstream work and downstream work in the business unit’s 
workflow. It must also be tested to determine its impact on the process and on 
downstream work that is outside the business unit. When the improvement can be 
determined to cause no harm, and maybe even improve other operational 
components, the change will be ready to be taken to a detail level needed for BPMS 
application generation. In cases where a BPMS is not used, the team will now need 
to define the lowest-level tasks and then create both business change specifications 
and IT application and legacy applications interface specs. Here the design and 


188 


Copyright ABPMP International 


Chapter 5. Process Design 


responsibility for the completion of the supporting applications will move to the IT 
department. If this non-BPMS approach is used, the project will need to coordinate 
resource needs with the IT department and have all work pre-approved and 
properly prioritized to save time. 

5. 6. 2. 2 Defining Activities within the New Process 

As noted above, it is necessary to look at a business design from multiple levels of 
detail to ensure no harm is done to downstream work or work that is handed back 
and forth with external groups. 

The activity-level "To Be" process models created earlier and their levels of related 
detail through subprocess, business function, activity in an organization unit, 
workflow, and scenarios, will be used to support this multi-layered view of the 
business. 

At this point, the activity level "To Be" business model will reflect the elimination of 
non-value added work. The analysis of the "As Is" models and information will also 
have produced a set of functional and non-functional business requirements, a list of 
business rules that must be considered (and where possible reused in the new 
design), a list of data requirements, and a list of current and needed IT applications 
support functions. The new design team will also have a list of business problems, 
change constraints, performance needs, operational standards and more from the 
"As Is" analysis. As a result, the design team will have an understanding of how the 
business really works, what the people performing the activity must really do, and 
what it takes to do it. 

5. 6. 2. 3 Designing Task and Scenario-Level Change 

Clearly, all levels of the Process Hierarchy must fulfill all requirements identified in 
the analysis of the "As Is" models and information collected during the discovery 
activity. But this is only the start of the new design. The unneeded work at all levels 
in the Process Hierarchy will have been eliminated from the design that the team 
will use as a starting point in the task- and scenario-level design. The problems 
shown in the Problem Matrix and the opportunities in the Opportunity Matrix must 
now be aligned to the tasks/activities/processes at the appropriate levels in the 
Process Hierarchy. This alignment will eventually affect the lowest level of work, 
where operational work and automation design will take place. 

This design will thus involve the workflows in business units and the scenarios and 
tasks that comprise them. All problems must be analyzed in terms of the root causes 
and all underlying factors addressed and eliminated. At "Break Point" (the places in 
workflows where errors and problems are noticed) the team must look at how the 
problems are detected (what is looked for in an initial identification) and define the 
characteristics that determine an error or problem. These characteristics are then 
used to analyze the upstream activity at the needed level of detail to determine how 
the problems start and then build. With this understanding, many problems can be 
designed out of existence and performance measurement put in place to make 
certain that any remaining problems are detected early and mitigated. However, in 
some cases where the cause is outside the scope of the project, it will be necessary 
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to note the cause and then design a way to mitigate the problem — deal with it, 
encapsulate it, improve the quality, etc., as soon as the information, document, 
product (etc.) crosses the boundary into the area of the business that is in scope. 

This will require work and thus cost, but it will be far less expensive to correct the 
problem at the boundary where it comes into the organization than later, at the end 
of the workflow. 

Business improvement opportunities identified in the Opportunity Matrix should 
also be addressed in the new design at this point. All changes needed to realize the 
opportunity should be defined and the design should be modified to deliver the 
opportunities. Here, however, performance measurement should be built into the 
workflow to measure benefit and report actual benefit against expected benefit. 

The new design should not have any non-essential work, the problems in the 
operation should have been designed out or mitigated, the business improvement 
opportunities should have been used in the redesign, and a specific improvement or 
evolutive approach to the change should have been selected. 

The team should now define the characteristics that would make the new design 
optimal and present them to participating managers for approval. These 
characteristics will be the foundation for performance measurement and the basis 
for determining project success. They are therefore important and the team should 
be careful not to overpromise on this characteristic list. This list should now be the 
main list of requirements. 

This list of success requirements should now be used as a checklist, and one by one, 
the team should make certain that all requirements are met in the new design. At 
this time it is also possible to identify groups of activities that will always be 
executed in given events, at given times, or as a result of some value in a decision. 
These can be grouped to form scenarios. A scenario is initiated and then each 
decision or grouping of data that is collected determines the next set of activity. That 
activity, in turn determines the next group of activity as the decisions or values 
determine the path that is taken through the scenario’s groups of activity. At each 
branch, however, the activity for the next group of work will always be the same and 
the result of a decision or value will always have a finite list of alternatives that are 
always chosen from in the same way. 

By looking at this work as related clumps of activities that provide a given decision 
or value, the work can be redesigned to direct activity through standard questions 
and answer-selection options. This can be used to embed decision logic and remove 
unneeded layers of human decision-making, unneeded layers of authorization, etc. 
Automated support can also be viewed in terms of its overall support for the 
scenario and its support for each work group within the overall scenario. All rules 
and logic can also be easily checked and measurement points can be clearly 
reviewed. 

But, the changes that have been made up to and including this stage of the redesign 
still may not make the design efficient. For efficiency, all business rules must be 
evaluated and normalized — because in many companies, the evolution of formal 
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and informal rules has resulted in redundancies, conflicts, definition problems, 
processing inconsistencies and quality problems. All rules must therefore be 
reviewed and proven to be both needed and effective. 

The design might still be disjointed, so the team will need to look at the flow and the 
way it branches. If possible the flow should be simplified. In this part of the design 
approach, the team should also highlight all manual work and eliminate as much of 
it as possible. If a BPMS is being used, the "white space” activity may be replaced 
with BPMS-generated applications. If a traditional draw tool is being used to 
support the design, it will be necessary to work with IT to determine what might 
realistically be automated, and when that could be completed. 

It should be noted, however, that shifting work to another organization or 
outsourcing it is not the same as eliminating it. The costs of the work may be shifted, 
but they are not eliminated and the company must still deal with them. 

As the team moves through this "To Be” design process, it is suggested that multiple 
concurrent versions of the new design be used as testing platforms for everything 
from wild ideas on fundamental change to more modest focused improvement. 
Results of these experiments should be closely reviewed and the best improvements 
added to the new business model. 

At this point, the changes should provide a streamlined business operation. If a 
BPMS is used, the team should run the changed workflow through the tool’s 
simulation capability to test for real operating improvement — run the "As Is" 
version and then the new version and compare the results. This will show probable 
benefit. Where inefficiencies remain, the team may want to perform a second design 
and optimize the overall workflow. 

The next thing for the team to evaluate is the need to manage the workflow and all 
activity. This will include identifying where work lists, ability to reassign work, and 
places to embed rules dealing with timing, volume, and other company standards 
exist. 

This is the point where management control is improved. If a BPMS is being used, 
the requirements for automated work listing, work assignment, work shifting (etc.) 
and reporting can be built into the new models and used to generate the BPMS 
applications needed to improve, control, and monitor performance. See chapter 10, 
"BPMS Technology," for more details. If a BPMS is NOT being used, the team will 
need to meet with the IT representative to determine what can be done in this area. 
The design will need to reflect this technology reality. 

As the new business design is in the later stages of its evolution toward an 
implementable business-operating solution, it will be necessary to design all system 
requirements and all screens that will be used. If a BPMS is used, this design is fairly 
straightforward as it is embedded in the models of the new design. If this design will 
be supported by more traditional IT services, the design may initially be fairly high 
level, but it will need to align directly to the business operating design. All 
documents that will be used and their flow must also be mapped to the business 
activity and accounted for in the new design. This may require the inclusion of 
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document management technology in the new design and in the requirements for 
interfacing. 

All data on every screen must be identified and, working with the IT data analysts, 
defined. All sources for this data, including new documents, customer calls, legacy 
applications, collaboration partners, etc., must be identified and aligned to the data 
capture points. All quality-related data edits must also be defined and aligned to the 
data capture and use points. This sets the foundation for the identification of legacy 
application use, change requirements, and consolidation. It also sets the 
requirement for data interfacing and new data transformation. The result of this 
part of the design is a set of data use and interface requirements. 

• The design should now be complete 

• All non-value-added work will have been eliminated 

• All problems will have been addressed 

• All business improvement opportunities will have been addressed 

• Rules will have been justified and normalized 

• White space (manual, under- automated work) activity will have been 
eliminated 

• Business scenarios will have been streamlined 

• All changes will have been reviewed for impact at all levels in the process 
hierarchy 

• All data use, transformations, and sources will have been identified, and 
interfaces with legacy applications will have been defined 

• All new automation will have been defined and designed 

• The design will have been compared against the original “As Is" design and 
evaluated for improvement 

• The project and the new business design governance will have been designed 

• Management performance, warning, and other reporting will have been 
designed. 

As with any design or requirement definition, the level of detail will be related to the 
difficulty of the change and the scope of the operation involved in the change. This 
level should be determined by the method and standards that are followed and by 
the need to support either a BPMS-application generation or a traditional IT 
application’s business and technical specification. 

Whatever level of detail is needed, will now have been reached in the design. It will 
now be possible to make immediate improvements and begin to build and 
implement the changes identified in the first of the phases (assuming an Evolutive 
Management approach) of the operation’s evolution toward optimization and rapid 
change. 

5. 6. 2. 4 Business Rules— an Ongoing Quest for Improvement 

Data is the life-blood of any business operation. If flows through it and keeps 
everything alive. Business Rules, in a similar analogy, are the "brains of the outfit." 
Rules define what will be done, when it will be done, where it will be done, why it 
will be done, how it will be done, and how it will all be managed or governed. The 
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need for quality in the rules that run the business cannot be overstated. If the rules 
are ineffective, the business operation will be ineffective and quality will suffer 
while costs increase. 

To add to this problem, most of the rules that are written in many companies are out 
of date and often conflict with one another. Rules are often added through memos 
and email, which people may or may not keep, or (at best) be added to the growing 
stack of paper in the front or back of the policy manual. Few business operations 
have paid close attention to this problem, and their current rules may not support 
policy or even legislation (the law). 

For this reason, any BPM project must be concerned about finding, listing, defining, 
and normalizing business rules. The team must also concern itself with how the 
rules are used and, if a BPMS or separate rules-engine will be used in the project, 
how the rules are "coded" into the tool. 

When defining business rules, the tendency in many organizations is to make them 
complex. Part of this tendency is a desire to reduce the number of rules. But the 
main cause is that many people tend to put entire decision trees in single rules 
instead of breaking the rules into single decisions and then linking the rules in sets. 
Aside from making the rules harder to test and use, this complexity in a set of 
business rules creates complexity in the process. The more complex the process is, 
the more opportunities for the process to fail. So, it is important to create company 
rules-definition and coding standards that keep rules as simple as possible. 

Each rule must be separately tested — both in written form and then, once coded, 
into a rules engine. The rules must then be tested in groups as they are used. The 
results should be reviewed by the Legal Department or Finance to ensure that they 
support legal and financial requirements. The rules should also be tested for 
efficient execution: if not properly coded, the rule can cause the application systems 
and thus the business to slow down. 

It is thus important that the team find all rules, ensure their applicability and 
quality, and verify that they are coded for maximum execution efficiency and 
effectiveness. 

Because rules change constantly and are (arguably) more volatile than any other 
component of the business operation, it is important that all rules be reviewed and 
confirmed for applicability at least semi-annually. The review should uncover 
changes, new rules, and new opportunities to eliminate any rule-related "white 
space" activity that has been created. While this represents ongoing work, it is a 
vital part of any attempt to sustain an optimal business operation. 

5.7 Change Management 

A great many good projects fail because the teams do not pay enough attention to 
managing the change and its acceptability to the business user. The simple fact is 
that the people who need to perform a new business task, use a new application 
system, measure performance and more, will resist the change if they have not 
accepted it or if they feel uncomfortable in performing it. 
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A great many books have been written on corporate culture and change control. 
Some companies have responded to this need to win staff acceptance of change by 
forming formal change-management groups and standards for dealing with change 
in both business and IT projects. In some companies, this desire to control the 
reaction to change makes certain that teams include the human perspective and 
ways of communicating intent, design, and reason to the business staff. 

Change is viewed in one of two ways. You are either doing something to someone, or 
you are doing something with him or her. The second of these views is obviously the 
one the team needs to build. The old-technology approach of a dedicated business 
subject-matter expert (SME) who decides what will be done and how things will 
work has proven to be inadequate in BPM. The changes are simply too invasive 
when a new way of doing business is the goal. A business SME was fine when 
delivering a tool (an application system) that was laid on top of the business 
operation, but the integrated business activity/tool design and use of BPM has 
created a different level of involvement from both the business- and IT-technician 
sides of the operation. 

The business staff will either embrace the change or find ways to prove it is a failure. 
If the majority feel threatened by the change, they will find ways to make it fail. That 
is reality. The purpose of this section in the chapter is to make readers aware that in 
BPM, a new level of change-control is needed, and any business design should 
include techniques that reassure business staff and engage them in the 
improvement. 

5.8 IT Infrastructure Analysis and Design 

New business operating designs may cause changes in both IT support needs and in 
the way the business operation is located in the company’s office and plant space. 
This may, in turn, have an impact on the IT infrastructure and the need for 
communication support. 

In addition, the data- and functional-support needs of the new business design will 
likely cause interface needs with legacy applications and requirements for data 
movement that may have a profound impact on IT strategy and infrastructure — 
including document use and retention, and data storage and delivery. 

If a longer-term business change design is used, following an approach like 
Evolutive Management, the IT infrastructure will need to be analyzed and aligned to 
the phases in the evolving business operation. This will allow the business change to 
be included in the IT infrastructure and in other plans and budgets. It will also allow 
the Enterprise Architects in the IT group to look at emerging technologies and 
application systems and leverage their understanding of this technology to 
continually look for the best solution at a given point in time, as defined in the 
business evolution plan. 

Some of the issues the IT organization will need to look at are: 

• What software or systems best match the needs of the process? 
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• Are there limitations in the current infrastructure that limit the design? 

• Can the design be implemented quickly? 

• How will a technology change impact the organization? 

• Can a staged approach be employed? 

• What will the new implementation cost (including training, technology, etc.)? 

• Are there vendors that can assist in the implementation? 

These and related questions should be looked at collaboratively between the BPM 
Architects, Enterprise Architects, and Business Architects to ensure understanding 
of business and IT alignment and requirements. This will also allow the BPM 
Architect to understand limitations faced by the IT group and the company’s IT 
infrastructure as it evolves. 

5.9 Simulation Modeling 

As noted above in the discussion on design, the new design should be tested before 
changes are built and IT applications are generated. The test will look at the likely 
result of the changes proposed in the design. This testing is a simulation of the new 
business operation and its IT support, either on paper or using the simulation 
capabilities of many BPMS tools. 

In this simulation, the "As Is" workflow will be used to define the baseline — the 
current activities and their relationships to one another. All decisions in the 
workflow will be used to simulate possible workflow branches. The probability of 
each decision outcome will need to be estimated as a percent. This will define how 
many times a given exit will be used — i.e. 10% of the time the decision is yes, 50% it 
will be no, and 40% of the time additional information will be needed. The 
simulation will also need to understand volumes, timings, and how many of a given 
transaction a person can process in a given period of time. This will now allow the 
team to test for break points, bottlenecks, and management needs (such as work 
shifting and rule changes). Simulating the current operation in the BPMS allows the 
team to modify the information until the simulation reflects the actual operation. 

The new process design will now be compared to the existing state in a gap analysis 
that shows the impact of the changes. This analysis provides important information 
that can allow the team to demonstrate the savings that can be generated by the 
new process, once the process is implemented. This helps confirm the improvement 
estimates in the business case for the new design, or provides an opportunity to 
adjust estimates and reset expectations. 

Once the "As Is" model and information provide the baseline for comparison, the 
team can test any number of possible design options. This testing is risk-free, since 
it is in a simulated operation. By comparing the operating and cost results of these 
simulations, the team can look for the best solutions and provide an estimate of the 
benefit. This ability to test designs and then quickly deploy the best simulation 
supports both rapid iteration and fast implementation of the change. This is critical 
in reaching optimization and sustaining that level of performance. 
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5.10 Conclusions 

The process design stage in a process improvement initiative attempts to define the 
new process state and outlines the steps necessary to achieve that state. Throughout 
this chapter the key activities, critical success factors, and suggested practices for 
achieving a successful process design have been discussed. The next step, addressed 
in the following chapter, is to implement the new design. 

5.11 Key Concepts 

Process design is the creation of a new process that aligns the business around the 
business strategy. 

Process design involves the executive leadership, process owners, and stakeholders 
in the creation of the new process. 

The process design team should include subject matter experts, stakeholders, 
participants, and customers. 

While designing a new process, consideration should be given to the following best 
practices: 

• Design around value-added activities. 

• Perform work where it makes the most sense. 

• Create a single point of contact for the customer. 

• Combine processes around clusters. 

• Reduce handoffs. 

• Reduce batch sizes. 

• Put access to information where it is needed the most. 

• Capture information once and share it with everyone. 

• Redesign the process before considering automation. 

• Design for desired performance metrics. 

• Standardize processes. 

• Consider co-located networked teams and outsourcing. 

• The activities associated with process design include the following: 

• Design the process with modeling and other tools. 

• Define the activities of the new process. 

• Define the rules of the new process. 

• Define the handoffs between activities. 

• Define the metrics. 

• Perform comparisons and benchmarking. 

• Perform simulation and testing. 

• Create the implementation plan. 

Critical success factors include ensuring the involvement of executive leadership, 
process owners, and cross-functional teams. 
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Foreword by David McCoy, Managing Vice President and Gartner 
Fellow Emeritus 

© Gartner, Inc. 2012. 

In the 2000 to 2001 timeframe, Roy Schulte and I were leading a team introducing 
his concept of Business Activity Monitoring (BAM) to the world, and we were 
finding resounding interest in the idea of monitoring "business activities" in real 
time through the use of event capture, filtering, and analytics. I remember one 
particular BAM presentation we did — the first full-blown BAM presentation ever 
delivered anywhere. It was a joint effort at one of our conferences and the audience 
was heavily technology-focused, to the point that several attendees came from the 
real-time automation world of manufacturing. We were proving the point that what 
works on the shop floor could also work in the business. Now, well over 10 years 
later, we find BAM to be a commonplace topic among BPM experts, and the notion of 
real-time process performance monitoring is hardly a tricky sale to the organization. 
But despite the established foothold that BAM has taken, the overall concept of 
process performance management is still a mystery to many, and the execution of 
this activity in most companies leaves a lot to be desired. 

To put it bluntly, it’s easy to measure and manage process performance — in the 
abstract; but when you actually have to deliver tangible value from the effort, we 
often fall short. This shortfall is sometimes related to the underlying technology: 
poorly connected systems, outdated infrastructure, rigid applications, and weak 
event-processing capabilities all lead to failure. But I think the biggest challenge is a 
three-pronged one of scope, value, and perspective. In other words, when we look at 
process performance management, we often find that we can measure and manage 
anything, and most often, that’s exactly what we do: we measure anything that 
moves, overlooking the more difficult opportunities that lie beneath the surface of 
our process world. 

A Problem of Scope: Consider an example that I wrote about in my Gartner blog at 
http://blogs.gartner.corn/dave_mccoy/2010/06/07/75-miles-per-gallon-down- 
blood-mountain-the-fallacy-of-metrics/. I travel up and down Blood Mountain in 
Georgia many times a year. As I ascend the mountain, my gas mileage plummets; but 
as I descend — basically allowing the steep grade and gravity to "do their thing” — my 
instantaneous gas mileage shoots through the roof. On a recent trip, I was able to 
peg the miles-per-gallon reading at 99, effectively hitting limits the programmers 
never considered realistic for a car that averages 25 mpg. I use this to illustrate a 
classic failure in process performance management: limited focus. 

If I were to divide the process of driving Blood Mountain into two sub-processes, 
Ascend and Descend, then a limited focus would say, "Just do the downhill part! The 
uphill part is too expensive." Well, that’s patently ludicrous, but what happens when 
we look at our business processes with a limited focus? We make the exact same 
mistakes. We don’t see the end-to-end process as the unit of measure; instead, we 
see the parts of the process as atomic and isolated, worthy of individual metrics, 
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measurement, and performance assessment. While there’s nothing wrong with 
analyzing processes with focused measures, if the measures are not part of a holistic 
framework — an end-to-end view — then you will make suboptimal decisions — 
decisions just as insipid as the idea that you can traverse Blood Mountain by only 
going downhill. This is the mistake of scope; it’s one that can be overcome with a 
proper understanding of the end-to-end perspective, the process major as opposed 
to the process atomic. 

A Problem of Value: Let’s assume we are looking at the end-to-end process and 
we’re not atomizing the holistic to unreasonable levels of scrutiny. Well, we’re still 
not out of the woods on process performance management because we can make 
mistakes in assessing the real value of the end-to-end process. Depending on the 
metrics we align to the process, we might be performing well on an end-to-end 
basis — according to our metrics — but totally blowing the mission. 

Misguided employee productivity measurements fall into this effort. What if your 
end-to-end process is called "desire-to-desk" and it’s a hiring process that takes an 
applicant from job opening to that first day at work. Is "cycle time" a reasonable 
measure? It is reasonable to want to measure the time it takes to recruit. There is an 
assumption that faster recruiting is an asset, so much so that it’s called "agility." But 
if that’s the measure, then how is the process performance managed? Well, it’s 
managed by a clock and calendar mentality. But in the end, the proper value 
proposition for our theoretical desire-to-desk process is "quality hires in a 
reasonable time.” Does the clock and calendar mentality worry about quality? 
Perhaps it does; but more often, it’s a discussion of speeds and feeds and not one of 
such nebulous concepts as quality. We’ve fixed the scope problem here; we are now 
looking at the end-to-end process from initial application to office assignment. But 
even though we are not atomizing the process, we are atomizing the value by 
selecting only a surrogate for what the true value should be. 

This is the mistake of value; to overcome this, you must fully examine the process in 
light of its proper contribution and extract the most salient outcomes that the 
process is seeking to deliver. In the end, a desire-to-desk process should not be 
about agility; it should be about pristine resourcing of your most critical resources: 
your employees. However, when firms treat the hiring process as a speed dating 
service, you get what you measure. To a bachelor, perhaps a speedy date is 
desirable; but to a hiring organization, the real value comes from a more 
comprehensive understanding of the true value of the process. For only then can 
you manage the performance in light of a proper outcome. 

A Problem of Perspective: Perhaps you’re convinced by my ideas so far: "I have to 
examine the end-to-end scope, not just a convenient atomization of the process. I 
must seek the real value inherent in the process, and manage it on that basis." Well, 
the final challenge is the most insidious: it’s the problem of perspective. This 
challenge is insidious because you can meet the first two expectations — scope and 
value — and still fail in the main. 
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Hear me out. All processes are based on perspectives. These perspectives come from 
the designer, the line of business, the IT shop, the consultant, the customer, the 
vendor, and so on. The idea of a perspective is typified by one of my favorite big 
words, Weltanschauung. Back in graduate school, I was privileged to study 
methodology design with some of the world’s experts, and we always seemed to 
come back to this term. Weltanschauung means "worldview,” and I’ve blogged on it 
a bit if you want more information. The bottom line is that your worldview — 
Weltanschauung — colors your perspective. It might even be said that it is your 
perspective. So, how you view reality colors how you design your processes. 

Now, let’s move from the theoretical to the practical. If your process perspective is 
that customers are cattle, it will be reflected in your processes. Your end-to-end 
processes can be measured in their entirety, and you can convince yourself that 
you’re measuring the proper value inherent in the process, but your customers will 
see through you and revolt. I've seen a few businesses that use a common tactic to 
increase sales. They want their employees to promote a certain account feature, 
food item, maintenance plan, etc., and the process states, "If, during the course of 
our transaction, we fail to offer you X, we’ll give you Y." The "Y" in question could be 
a discount, or a free token item, or a rebuke to the sales person. The process 
perspective is clear: "You, the customer, are a walking-talking pocketbook and we’re 
going to try to up-sell you at every chance we get." This is easy to measure on an 
end-to-end basis: were you offered the item being promoted, as part of the overall 
process? And the process value to the organization is pretty clear — increased sales. 
But, how do you feel about being told that you’re a pigeon in a cross-sale 
opportunity? How do you feel being warned that you’re going to be pestered with 
add-on sales? 

The process perspective here is insidious because the process itself is broken. The 
Weltanschauung of this process says, "My worldview is that you are a source of 
revenue that I am to maximize." In the end, does this process really work? If you 
manage it well, have you really managed to deliver success? On one hand, you 
deliver cash to the bottom line; on the other, you infuriate some customers who 
object to your blatant high-pressure sales tactics, all candy-coated with the offer of a 
freebie if you actually escape the sales tactic whole. In the end, process perspective 
becomes a close partner with real value. But it’s unique enough to call out. 
Weltanschauung is a fancy German word, but it’s one worth examining. How you 
view your process stakeholders is determined by Weltanschauung — yours and 
others’ — and it will frame the way in which you assess overall process value and 
resultant performance management actions. 

Overcoming these three pitfalls to process performance management will not assure 
you of success, but these are traps that you want to avoid. Often, these traps are easy 
to spot in retrospect, but who wants to live life in a series of apologies for having 
weak process skills? Also, these traps are combinatorial: they pile on you like a bad 
game of Rugby where you’ve got the ball, and scope, value, and perspective kick you 
with their cleats. They really are an ugly trio, so you must spot them and exorcise 
them from your practices. Whether your process performance management efforts 
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are BAM-driven or just old-fashioned MBWA (management by walking around), do 
your best to define processes, metrics, and measures that are properly scoped, 
based on the real value being delivered, and designed from the proper perspective 
of the real stakeholders. To do anything less is just asking to be labeled as irrelevant 
to process performance management. 
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6.0 Introduction 

Process Performance Management involves both an understanding of what to 
measure and how to measure it. This chapter is thus divided into two basic 
sections — what to measure and (basically) how to measure performance. 

Performance measurement is the foundation for performance management, and if 
the organization does not have the performance management maturity to support 
often-complex performance measurement, the results of the measurement can be 
misinterpreted and cause harm instead of good. 

This chapter thus devotes considerable space in Section 1 to discussing performance 
management maturity in order to help company managers understand where their 
company stands in terms of its ability to support performance monitoring and 
measurement and to interpret the outcome of measurement activity. 

The second section of the chapter is more mathematical and more concerned with 
how you measure performance. Successful performance management requires a 
mastery of both aspects of this issue and the design of an evolving, customized 
approach to determining the company’s true performance as related to individual 
processes. 

This focus on process will be new to many, since the usual focus is on financial or 
business unit measures. While these are certainly valid, we are proposing a different 
group of measures — related to process. These provide a comprehensive 
understanding of how the overall process is performing and help focus process 
optimization. 
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Process Performance Management Section I 
6.1 What is Process Performance Management? 

The term Process Performance Management is normally used to indicate the 
management of the business operation at both a process level (cross-organizational) 
and a workflow level within a given business unit. In a BPM context, it further 
indicates that some degree of flow management is taking place to (1) identify 
backlogs and shift or redistribute work, and (2) to identify quality problems in time 
to correct them. This implies control over the way work moves, consistent response 
to events, quality measurement (real-time) and control over the rules that direct 
work. 

This definition is applied differently at the process and workflow levels: the scope 
and level of monitoring change as one moves to process from workflow. 

The biggest issue with the process-level use of performance management is that 
many companies lack a good understanding of what their processes are or how they 
work. In earlier chapters we define process as being cross-organizational. While 
there are different ways of identifying and grouping processes, they can basically be 
identified by working backward from an end-product or service. That implies that 
they produce a higher-level view of all the work needed to deliver the product or 
service. 

For purposes of this chapter, we will not go into process definition or classification. 
However, a discussion of process management must begin with a look at process 
'today.' 

It is easy to assume, when looking at performance in a process, that the process is 
doing the right things and that management should focus on efficiency instead of 
effectiveness. This is not a good assumption. The place to start any management 
activity is with a look at the current effectiveness of what will be managed. If it is 
accomplishing the wrong things, efficiency doesn’t really matter — there is no benefit 
in doing the wrong things faster and more efficiently. So, we suggest that process 
performance management begins with examining the process or processes that will 
be monitored for performance. 

Assuming that the processes have been identified and defined correctly, we need to 
ask if a process is effective — does it deliver what it is supposed to? At that point we 
can ask if unnecessary subprocesses or activities are being performed. In this 
review we also need to break with the past and ask if the process includes 
everything needed to produce the desired outcome. Everything should be justified 
based on its contribution to the delivery of the end-product or service. Lean 
techniques are good in this evaluation. The goal is to ultimately improve what we 
need to do, not simply what we are doing today. 

You should not assume that everything was okay or right to start with — everything 
should be reviewed and justified. Consider asking: 
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• Why are we in the businesses we are in? Are they exclusive of one another? 

• What markets are we in, and what are the challenges of these markets? 

• What does the competition do better than we do? 

• Who is our target customer and what are they looking for? 

• Are we giving them what they want? What do they think of us? 

• What do we need to do to support our business? 

• Does the current business process support a strategic goal? 

• What are the biggest problems or challenges we face? 

• What problems do we need to solve first? 

• What do we need to do solve them? 

It should be noted here that cheaper is not always better. Some people buy a Ferrari 
and others a Ford Focus: along with other factors, understanding the customer’s 
motivation for buying your product or service is critical to the business. It is the 
foundation for any review of a process and its evolution to optimization. Without 
this understanding, you might limit performance measurement to the usual time 
and motion issues, or fail to understand "quality” and quality requirements as 
anything more than abstract targets. While traditional measurements are important 
to operational optimization and a good starting point, they do not really help ensure 
that the company is evolving to a model that better serves the customer. Both 
efficiency and effectiveness are needed to ensure company health. 

Once process(es) are identified, defined, and understood from both an internal and 
customer point of view, management can create an approach to performance 
definition and then measurement that will allow the measurement to evolve as the 
business and process(es) evolve. This is the only way to avoid a program where you 
start measuring the right things, but drift away from the business as it changes. 

6.1.1 Tying Process to the Organization 

In this review, all subprocesses and their links to business units and thus 
organization must be tracked. All process-level and subprocess-level changes will 
affect the business units that support them and any change at these levels will need 
to be reflected there. This linking allows management to understand the big picture 
and deal with change from a process perspective; it also fosters thinking about, and 
understanding of, the dynamic interaction between processes in any process 
redesign. 

From this perspective, managers can also understand who is involved in each part of 
the process and what their role is in making it function. In this context, "role" means 
responsibilities; here, individual responsibilities can be combined into specific roles. 

This will help everyone understand who should be involved in any performance 
measurement and in any corrective action that may be needed. Of course, this 
should all be modeled, using the supporting information associated with each 
subprocess and at lower levels of activity in business units. 
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One of the major problems with moving into process-level performance 
management is that the reviewer can be too close to the process or so accustomed 
to it that its failings aren’t apparent. For many, the current processes seem to look 
right, but when objectively analyzed using BPM techniques, weaknesses and 
unneeded work can often be found. 

At this point, a new set of concerns becomes relevant in finding what to measure. 
Apart from the usual operational performance issues (as discussed later in this 
chapter), optimization requires more than measuring the physical movement of 
widgets and optimizing their time through the build-process. Every activity has a 
customer. Every customer has a need and can be harmed by unexpected outcomes 
from the previous worker. Measuring movement and expected outcome is a 
necessary good start. Measuring exceptions is also a good baseline measurement. 
But how much more would you get if you measured customer experience in their 
work and in the end-activity of the process — someone buying something and 
interacting with the company? 

Each worker makes decisions every minute of the day. Some follow rules, and some 
don’t. It is impossible to have rules that govern every situation: the legal system has 
tried that and so has the IRS. Both created such a complex mess that professionals 
have had to be used in both cases and they still deal with gray areas and 
interpretations. 

Also, support quality must be considered. Are the IT applications comprehensive — 
do they really support the work? Are they hard to use? Do workers need to log in 
and out of applications to do simple tasks? How are issues resolved? Are they 
resolved in a timely manner? 

These and other base issues need to be understood in looking at performance and in 
measuring it. Such understanding is also necessary in looking at performance 
results and in requesting improvement projects. 

It is important to note that performance measurement can be hierarchical and 
measure process, subprocess, workflow and activities separately to create a drill 
down capability as the information is linked. 

In looking at process, the team will likely run into both organizational and political 
silos. These silos build brick walls around work and limit how BPM and process 
management can be performed. This is the tough part. It is also the part that will 
vary by company and person, so must be dealt with differently in every situation. 

6.1.2 Process Maturity Determines What is Reasonably Measured 

When considering process performance management, companies need to look at 
what is realistic through the lens of their process maturity level. 
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Process Maturity: The characteristics and capabilities that 
define the current state of the company’s move to 
understanding and managing processes. 


Process Maturity Models represent a journey from a strictly organization view of 
work to an integrated process focus. At different points in this journey, the company 
will generally fit into a given maturity level or stage based on characteristics that 
can be defined and aggregated to form a description of the company’s ability to 
understand and manage their processes. The company’s ability to measure work 
performance at any level (from individual task quality to workflow to process) is 
related to their level of process maturity, because at every level of maturity the 
company will understand process a little differently and will have built the 
infrastructure to support it at that level of maturity. For example, if a company is at 
the beginning of its journey to process management, it will not have an 
understanding of process or the interaction among its processes. It will also lack the 
ability to understand how work aggregates and how it should be measured. At this 
level, Process Performance Measurement is simply not possible. The same is true for 
data. If the company doesn’t have the ability to easily access data from all the 
applications involved in supporting a process, it cannot become involved in certain 
types of performance measurement or in comprehensive business intelligence 
reporting. So the position of a company in a process journey (shown in the Process 
Maturity Model) can help properly set performance measurement capability 
expectations and show a clear road to improved monitoring, measurement, and 
reporting. 

Note: The ABPMP definition of process is assumed in this discussion. In summary, this 
is the identification of all the activities needed to produce a complete product or 
service and the aggregation of the cross-organization work that is involved. 

Often the desire for performance management and reporting is not supportable 
because a disconnect exists between what a company can reasonably measure and 
management’s need for control and measurement. So, in starting to look at Process 
Performance Measurement, it is necessary to assess your level of process maturity, 
which is not an easy task given that many companies misunderstand what process 
is, what their processes may include, or how they interact. 

A further problem is that few people want to hear that they need to change the way 
they look at their organization or that they must rethink what they consider to be 
standard terms or definitions. Convincing people to change themselves and their 
perspectives is even harder than convincing a company to change. Companies resist 
change — no news there. But people hate change and sometimes go beyond 
resistance to actively fight it. The fight can be insidious and take a variety of forms: 
have you ever had people make commitments and then just not live up to them? 

That is where a Process Maturity Model becomes helpful, as it creates a framework 
that people can understand and relate to. It also helps them accept the journey or 
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decide to reject it and stay where they are. In either case, it helps define the future 
strategy and approach to process and thus to Process Performance Measurement. 

If accepted, the Process Maturity Model will provide the guidance needed to define 
and build a process evolution plan. This plan will show where the company believes 
it is in the maturity journey and what it needs to do to move to the next level. This 
then determines the projects and tools that are needed and helps set process 
measurement expectations. 

To help management understand this journey, we strongly suggest the use of an 
accepted, formal Process Maturity Model. Internally developed ones are customized, 
but may not be as well thought out as the industry-accepted models. They are 
certainly not as defensible. 

It is important to note that companies may have different business groups, divisions, 
lines of business, subsidiaries, etc. in different maturity levels. This is also true for 
individual processes. Some may be defined and others not yet identified. The use of 
the model must therefore be part of a defined/formal process management strategy 
with a roadmap showing the current state of process understanding and 
management, and the roadmap to implementing it broadly in the business. 

There are many formal models to choose from, and the trick is to find one that is 
acceptable to the majority of managers in the company. Adopting one then allows 
you to build a process management maturity-improvement roadmap and process 
measurement capability around it. However, care will need to be taken to find and 
accept a model and approach that is business-based and not IT-based. Technology 
helps support processes and process measurement. It does not define them unless 
you have a mature BPMS-supported BPM operating environment with models of the 
entire company and its rules entered into the BPMS. See chapter 9, "Enterprise 
Process Management," for additional information. 

For this chapter we chose the framework from the Forrester Research Process 
Maturity Model. However, as noted, Gartner and many others have good Process 
Maturity Models that you should review for best fit in your company. 

Forrester Research divides Process Maturity into five stages or levels, as shown in 
the table below. 


Process Maturity 
Level 

Process Understanding and Characteristics 

0 — nonexistent 

Not understood, not formalized, need is not recognized 

1 — ad hoc 

Occasional, not consistent, not planned, disorganized 

2 — repeatable 

Intuitive, documented, understood, occurs as needed 

3 — defined 

Documented, predictable, evaluated occasionally, understood 

4 — measured 

Well-managed, formal, often automated, evaluated frequently 
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5 — optimized 


Continuous and effective, integrated, proactive, usually 
automated 


For more information, please see the corresponding Forrester report, "Find Your 
Transformation Edge." 


Table 11. Forrester Process Maturity Model, September 2011 


Discussions show that most companies are in the 0, 1, or 2 range of maturity in the 
Process Performance Measurement model. Although many are trying to move to a 
process orientation and thus to higher levels of process maturity, few have made the 
transition. Carrying this model further to focus on process performance 
management, we see that performance measurement capabilities can be tied to the 
levels in the Process Maturity Model. 

Part of the reason for this alignment is that even in the most sophisticated IT and 
business operation, measurement is tied to understanding. If a company doesn’t 
understand process, it cannot look at it cross-functionally, and it can only measure 
performance in the separate business units. It cannot tie this information together 
to look at broadly-related aggregations of work — real process. This has an impact on 
performance measurement, quality monitoring, costing, problem resolution and 
more. 

Using the Forrester Process Maturity Model, we see that performance measurement 
takes on different forms for different levels of maturity. These forms build from 
level to level as new monitoring, measurement, and reporting capabilities are added. 
They also assume an IT and business environment that can support automated 
monitoring, measurement, and reporting. In the early stages of process maturity, it 
is also assumed that many companies may want to manually check activity through 
manual work reviews to confirm measurement against KPIs and product audits for 
quality. 


Process Maturity 
Level 

Performance Monitoring, Measurement and Reporting by 

Maturity Level 

0 — nonexistent 

Isolated Six Sigma, Lean, activity-based costing etc. 
performance measurement — mostly workflow oriented with 
some attempts at process identification and monitoring 

1 — ad hoc 

Isolated performance measurement with special quality and 
operational problem performance measurement — mostly 
workflow oriented with a growing understanding of process 

2 — repeatable 

Ongoing programs of performance measurement — different 
ways of measuring performance are used for different groups 
in the company (often workflow oriented) 

3 — defined 

Process is separated from workflow and the distinction is clear 
in the company — performance is generally measured at the 
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Process Maturity 
Level 

Performance Monitoring, Measurement and Reporting by 

Maturity Level 

end of the process and workflow; performance management is 
formalized and a consistent approach is taken 

4 — measured 

Performance measurement is now added at key break points 
in the processes and workflows; operational performance 
management is guided by real-time or near-real-time 
dashboards; Business intelligence reporting for trend analysis; 
business rules, process and workflow designs and their 
technology support are now reviewed based on performance 
measurement and optimized 

5 — optimized 

Performance measurement guides continuous improvement; 
changes are measured as they are implemented and on a 
regular cycle to determine benefit; Six Sigma and other 
techniques are used to help guide focused improvement; 
strategic changes are supported 


Table 12. Process Levels 


Following the levels shown above, a company can organize a journey through 
performance measurement that ties its ability to understand its processes to 
measurement and its ability to support solid automated measurement programs. 
The discussion below also refers to the maturity levels of the Forrester model. A 
detailed list of things that may be considered in building a performance monitoring 
and measurement capability is presented later in this chapter. 

6.1.3 Evolving Ability to Measure Process Performance 

Note: Discussions in the black text boxes are from the Forrester Research Process 
Maturity model. Discussions in the blue text boxes are on Performance Measurement 
for the maturity level in the linked black text boxes. The blue text boxes are discussions 
from theABPMP author. 


0 — nonexistent 

Not understood, not formalized, need is not recognized 

(Process Maturity 
level from 
Forrester) 


0 — nonexistent 

Isolated Six Sigma, Lean, activity-based costing etc. 

(Performance 
Measurement from 
ABPMP) 

performance measurement — mostly workflow oriented with 
some attempts at process identification and monitoring 


Table 13. Process maturity description for level 0 
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A great many companies are strictly organizationally oriented and have not yet been 
concerned with process (as described above ). Others are aware that there must be 
processes in their companies but look at them as a few steps within business units. 
These companies are at the beginning of their BPM journey. 

At this stage in its evolution, management can expect many differing opinions on 
what process is and how it should be measured. Some groups will try Six Sigma at 
this point, but it will not have a broad (process) application and will have limited 
impact. 

Performance monitoring will be virtually unknown and the company will have very 
limited ability to monitor work, measure improvement or success in meeting 
standards or KPIs, and evaluate performance. Measurement at this stage in the 
company’s process evolution will be rudimentary, and special-purpose, after-the- 
fact reporting will dominate performance reporting. 

As mentioned above, because companies at this level of process maturity don’t 
know their processes or the work that makes them up, they don’t have the ability to 
measure process performance. Performance measurement at this process-maturity 
level is focused to help drive event, workflow, or problem-specific measurement. 
Reporting is generally limited and the ability to combine data sources for business 
intelligence reporting is generally still in the future (see Table 14). 


1 — ad hoc 

(Process Maturity 
level from 
Forrester) 

Occasional, not consistent, not planned, disorganized 

1 — ad hoc 

(Performance 
Measurement from 
ABPMP) 

Isolated performance measurement with special quality and 
operational problem performance measurement — mostly 
workflow oriented with a growing understanding of process 


Table 14. Process maturity description for level 1 


As companies recognize a need to view process, many become aware that they are 
inhibited by their lack of process understanding. As they begin to understand what 
process is, they often recognize that their processes are inconsistent and produce 
various results. At this point many turn to using Six Sigma, Lean, or other 
improvement approaches at a broader level and do gain some benefit. But these 
efforts are usually reserved for more progressive business areas and core processes. 

Performance measurement is generally focused on given quality issues or business 
unit cost reduction — usually through staff reduction. Performance measurement 
now becomes a goal for many managers — but not all. Some managers also try to 
move toward identifying cross-functional processes and build process models. The 
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models are generally simple and do not have monitoring or performance-reporting 
capabilities. 

However, without process identification backed at the executive level, concern for 
Process Performance Measurement is often uncoordinated and limited to the 
portions or process within a business unit — in effect, workflow. Reporting still 
cannot consider true processes; only some parts of processes are recognized as 
being related, and performance measurement cannot be embedded in what is still 
not generally known (process). Measurement capabilities are still focused on a few 
tasks in a workflow and broader performance measurement cannot be 
accomplished. Broad-based performance measurement is generally not available 
because only some of the business unit managers in any process will have accepted 
attempts to measure their work (see Table 15). 


2 — repeatable 

(Process Maturity 
level from 
Forrester) 

Intuitive, not documented, occurs only when necessary 

2 — repeatable 

(Performance 
Measurement from 
ABPMP) 

Ongoing programs of performance measurement — different 
ways of measuring performance are used for different groups 
in the company (often workflow oriented) 


Table 15. Process maturity description for level 2 


A growing awareness of process becomes manifest in attempts to gain an end-to- 
end view of the activities of some localized process. Some managers now attempt to 
improve the way processes work by identifying KPIs. Understanding business rules 
now becomes important. However, processes are still not identified completely and 
few, if any, are accurately documented. Simple modeling tools may be in place, but 
models vary in content and quality, and few are kept up to date. There is also no tie 
between daily work and these early process models. 


Measurement of any kind is still relegated to focused Six Sigma studies, manual 
audits of workflow for quality, and manual "piece work" counting. Systems data is 
still separate and there is little ability to combine information from multiple systems 
and databases without custom programming. Reporting is improving, however, as 
managers start to understand process and their roles in the processes they support. 


Because process awareness is taking place, management may force a manual 
combination of information for performance measurement. For those processes that 
have been defined, Process Performance Measurement is still fundamental and 
inflexible. It also requires a great deal of custom programming. 


3 — defined 

(Process Maturity 


Documented, predictable, evaluated occasionally, understood 
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level from 
Forrester) 


3 — defined 

(Performance 
Measurement from 
ABPMP) 

Process is separated from workflow and the distinction is clear 
in the company — performance is generally measured at the 
end of the process and workflow; performance management is 
formalized and a consistent approach is taken 


Table 16. Process maturity description for level 3 


However, at this time, most processes are not identified and defined. BPMS tools are 
in place and significant parts of the business are now run using BPMS-supported 
BPM operating environments. Process is now fully visible, along with all its 
interactions with other processes and external partners. Management understands 
what they are and has visibility through formal cross-organization process models. 
Processes are now decomposed to subprocesses, then linked to business 
organization units and, within them, activity and workflow. Application use is now 
visible and problems are defined. 

Legacy and purchased/leased applications are now linked to the BPMS-supported 
business operations and defined for those business operations that are not using a 
BPMS to support change and operations. Data is now generally available for 
reporting from the BPMS and legacy applications. Formalized performance 
measurement is not widely available, but must still be defined and evolved to 
provide a growing need for operational information (see Table 17). 


4 — measured 

(Process Maturity 
level from 
Forrester) 

Well-managed, formal, often automated, evaluated frequently 

4 — measured 

(Performance 
Measurement from 
ABPMP) 

Performance measurement is now added at key break points 
in the processes and workflows; operational performance 
management is guided by real-time or near-real-time 
dashboards; Business intelligence reporting for trend analysis; 
business rules, process and workflow designs and their 
technology support are now reviewed based on performance 
measurement, and optimized 


Table 17. Process maturity description for level 4 


This level is characterized by the full implementation of a BPMS-supported BPM 
operating environment. Processes are well defined in these companies and are 
formally managed. This management is usually a type of secondary structure that 
works with the organization. Here both process performance and workflow are 
measured (1) in near-real-time for operational intervention to resolve problems and 
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(2) for business intelligence and improvement reporting. Six Sigma and normal 
operational metrics are measured and used to guide the business. 

Performance measurement is now integrated into the business operations and near 
real-time-dashboards report backups, problems, and often offer action 
recommendations through the use of inference engines related to event or 
situational business rules. Performance measurement now begins to make a 
transition from after-the-fact reporting to real-time performance management. 


5 — optimized 

(Process Maturity 
level from 
Forrester) 

Continuous and effective, integrated, proactive, usually 
automated 

5 — optimized 

(Performance 
Measurement from 
ABPMP) 

Performance measurement guides continuous improvement; 
changes are measured as they are implemented and on a 
regular cycle to determine benefit; Six Sigma and other 
techniques are used to help guide focused improvement; 
strategic changes are supported 


Table 18. Process maturity description for level 5 


Continuous improvement can now be implemented (see Table 18). The 
organization’s operating changes can now be quickly reflected in the processes and 
their supporting applications and data. Legal mandate can now be implemented 
quickly, and changes directed by performance measurement tools/techniques such 
as Six Sigma can now be designed/tested/implemented within weeks. This 
environment allows change to happen quickly enough to continuously react to 
improvement opportunities, first optimizing the business operation and then 
continuing to optimize it as issues are identified or required changes are defined. 

Performance measurement is now built into the processes through the use of BPMS 
and external reporting tools. Both traditional performance management and 
business intelligence reporting are now used to identify problems and quickly make 
the changes needed to resolve them. 

6.1.4 Setting the stage 

This state is the final point in the evolution of process management and 
performance measurement. Here the two are melded into one, where measurement 
drives management. This journey will have taken years for most companies and 
represents a long-term strategic commitment on the part of executive management. 

Before performance measurement is seriously attempted, however, it is 
recommended that a company honestly evaluate where it stands on its journey to 
process management and its capabilities in supporting any measurement or 
approach. 
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6.1.5 Solving the wrong problem 

Care must be taken in building any performance measurement system to ensure 
that it focuses on the right issues and the right parts of the process. To help identify 
the things you will measure, consideration must be given to legal reporting 
requirements, financial reporting requirements, performance against KPIs and 
milestones in the work, backlogs and volumes against standards, quality against 
standard, scrap, error, and more. 

But beyond these normal performance measurements, consideration should be 
given to inference, trends, and satisfaction of various internal and external 
customers as the outcomes of work move from subprocess (and business unit) to 
subprocess. 

These will not all be applicable to every company. There is no one list that fits all 
situations. 

6.2 What is process performance? 

Simple question, but not a simple answer: "It depends." That is the problem. 

Because companies operate with different levels of performance understanding and 
with very different technical reporting capabilities, this can actually have a few 
definitions. 

Process Performance: The measurement of specific 
operational characteristics as defined by Key Performance 
Indicators (KPIs), standards, labor contracts, the finance 
department, industry best practices, ISO, and others. In this 
measurement, the company will be looking at one or more 
processes and their interactions to determine their 
performance against these measurement criteria. 


Some of the questions to ask in figuring out what process performance means are: 

• What type of performance are you talking about? — For example, cost? 
Against what measure? — Quality? Quality of what? And how is it defined? — 
Cycle time per widget? 

• Against what measure, and what are the components? Here, for example, is it 
just speed, or is it speed with quality? 

So the answer is not really straightforward. It relies first on your definition and 
what you are trying to measure, against what measure or standard. And to make 
things a little more complex, the definitions of any measure will vary by industry, 
line of business, department, and manager. That is why any performance 
measurement must begin with the identification of what you will measure, why you 
will measure it, and against what values you will evaluate it. Without this you may 
very well measure the wrong thing, in the wrong way, and against arbitrary limits. 
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To deal with this, it is recommended that you start with a workshop and look at the 
object of measuring performance, which is not very straightforward. It is 
definitional and thus open to interpretation. Without control, no one can win 
anything that is measured by interpretation. 

So, first comes the list of what to measure and why. Here it is important that all the 
right managers attend the workshop. If they don’t attend the workshop, they will 
not buy into this. That means that any measurement will be subject to debate and 
the results will not be accepted by some. The fact is that if managers do not attend 
this workshop, the movement to performance measurement is destined for failure. 

If this is the case, it is suggested that higher authority be brought into the movement 
and participation mandated. If this is resisted by higher authority, failure is 
inevitable and measurement will be relegated to small parts of the business — 
workflow or lower yet, task operation. Here a single manager will still need to back 
the effort. 

Workshop measurement list: 


Goal of measurement 

Thing to measure 

Measure against 





Once everyone has agreed on the list of things to measure, it will be necessary to 
look at how they will be measured. Here process, subprocess, or workflow will be 
added to the list’s measurement definitions. 


Goal of 
measurement 

Thing to measure 

Measure against 

Where to measure 






Next the workshop managers will need to identify what will need to be measured to 
produce valid results. 


Goal of 
measurement 

Thing to 
measure 

Measure 

against 

Where to 
measure 

What to 
measure 







Finally, the workshop managers will need to identify each measurement to be made 
(the formula, count, etc. and what they will be measured against — standard, KPI, 
etc.). 


217 


Copyright ABPMP International 






Chapter 6. Process Performance Management 


Goal of 
measurement 

Thing to 
measure 

Measure 

against 

Where to 
measure 

What to 
measure 

How it 
will be 
measured 








If a person or group will be responsible for the measurement and its 
quality/accuracy, they will be added to the measurement information. 


Goal of 
measurement 

Thing to 
measure 

Measure 

against 

Where to 
measure 

What to 
measure 

How it 
will be 
measured 

Responsible 

for 

measurement 









If needed, more supporting definitional or other information can be added. As with 
all of these suggestions, the list in these charts can be modified to support company 
needs. Accordingly, what is measured is a secondary concern here, because it can 
change over time as the managers become more sophisticated in their use of this 
information and the company moves to more mature levels in its journey through 
process performance management. The important thing is that the managers who 
will be held accountable for the results of the measurement need to participate in 
the creation of both the measurement approach and the measurement formula. 

6.2.1 Reality 

Although this endeavor is great in theory, it is different in practice. First, in most 
companies, it is informal. Companies like UPS, which has well-defined processes and 
measures everything, should be considered exceptions because they represent fairly 
mature process-focused management. Other companies, like Sloan Valve and 
Raymond James Financial, are on their way to changing their focus to include a 
process view. Once that is completed, process performance management is not far 
behind. 

In the move toward process performance management, it is important to realize 
that what management initially considers an important indicator of performance 
will be temporary: it will change as more information becomes available and they 
are able to manipulate it in increasingly flexible ways. This change will likely be tied 
to the level of process management maturity in the company. While the exact 
reporting needs cannot be predicted, it is a good bet that use of the information will 
become more sophisticated over time as the ability to access and query the data 
improves. 


218 


Copyright ABPMP International 


Chapter 6. Process Performance Management 


For most companies today, a process perspective will be fairly new, and measuring 
its performance will be newer. Managing expectations at this time is thus very 
important. It will be easy to overpromise and fail to meet expectations, which will 
cause serious confidence damage. For this reason, ensure delivery of support based 
on a realistic evaluation of the company's ability to support measurement — before 
making promises. 

6.2.2 How does Process Performance Measurement differ from workflow 
performance measurement? 

As noted earlier in the CBOK and in this chapter, we find that a great many 
companies define process and process management as the work that happens 
within a given business unit. ABPMP officially disagrees with this definition, but for 
many companies it reflects reality and needs to be addressed. 

In practice, workflow can be measured in much the same way as process except that 
it refers to the activities in a business unit and their application systems, rules, 
databases, data, web services, web portal applications, interfaces and legacy 
applications. These are part of a process, and this information will need to be 
aggregated with that from related work in different business units to form a process. 

However, depending on where a business is in its process maturity journey, 
workflow performance measurement may be all that is either appropriate or 
available. Apart from process maturity level, too, it is very possible that an 
improvement effort will focus on a business unit’s workflow activity or the activity’s 
tasks. This is especially true for many customer experience improvement projects. 

In these projects, performance will be measured in terms of improvement at the 
project’s level. This may require special consideration in designing the solution and 
retrofitting performance measurement into the workflow. 

"Process" as defined by ABPMP is cross-organizational and takes in all work of any 
type needed to build and deliver a product or service. Here process can be broken 
into subprocesses and the subprocesses performed by business units as a series of 
interrelated and sequenced activities — workflow. Once this structure is known, the 
processes can be monitored by aggregating information from the workflow level 
and for the handoffs between the business units. 

If a BPMS-supported BPM operating environment is in place, this measurement is 
fairly straightforward and the information can be obtained from the BPMS and 
associated databases. However, if the business unit is supported by traditional 
applications systems, the collection of this information will need to drive custom 
monitoring-and-measurement programming and the modification of existing 
interfaces to legacy application data (from all the applications that are used in each 
business unit that is part of the process being measured). 

The questions that can be asked and answered vary by the level being queried — 
process or workflow. At the workflow level, the focus must be on the physical 
movement of work from one activity to the next and the places where quality or 
other problems happen. At the process level, the focus is on the movement of work 
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between business units and the quality of what is handed to the next business unit 
downstream in the work or process flow. At both levels, however, the things being 
measured will be fairly consistent — cycle time, quality, decision accuracy, etc. The 
difference is thus context, and how the information can be applied to improve the 
operation. 

6.3 What can Process Performance Measurement tell you? 

To a large degree the answer is "that depends." It is related to several factors, 
including 

• Level of flexibility in accessing data from multiple applications 

• Process understanding — process maturity level 

• Sophistication in asking performance questions and measuring activity, 
quality, etc. 

• Agreement on what to measure and how to measure it 

• Ability of IT to build flexible performance measurement applications 

• Reporting presentation and data drill down 

• Acceptance of performance measurement by those who will be measured. 

Note: the order of items on this list does not represent importance, difficulty, etc. 

Assuming these issues are addressed and do not limit a company's ability to 
monitor, measure, and report performance, this information can be the foundation 
for both immediate and continuous improvement. 

Because the ability of any company to measure process performance is directly 
related to the types of capabilities listed in the Process Maturity Models, it is 
necessary to tie these models to the company’s measurement and reporting 
capability in order to set information expectations and create a measurement 
evolution plan. This allows the company to put in place the underlying 
measurement capabilities it will need for any measurement individually. 
Management can thus determine what information they need and then understand 
what it will take to build the ability to get and report on that information. 

For many managers, collection of this information is directed to support certain 
measurement approaches, such as Six Sigma or Activity Based Costing. For others it 
will be more strategic and support Business Intelligence reporting with drill down 
and simulation. However, performance measurement can provide a comprehensive 
look at the business operation at any level of detail — process, workflow 
(organization), or task. Some of the things that may be measured are shown later in 
this chapter. 

In reality, a company's use of process performance reporting will evolve. Initial uses 
may lead to some or many of the wrong things being measured, and thus the story 
that the data tells may be incomplete, partially wrong, or of limited use. As 
management’s understanding of the information and how it can be used improves, 
the type of information and the way it is presented will change. This creates an 
evolution. The speed of this evolution is based on actual use of performance 
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information — the more the information is used, the more management will learn 
about their real reporting needs and the uses the information can be put to. And, as 
with all good things, the more benefit something provides, the faster demand for it 
will increase. 

Creating this level of use, however, requires time and commitment. Managers will 
need to go through the lower-value startup of the company’s performance 
measurement program to evolve to the high-value stage. This is noted here to help 
set expectations. 

6.3.1 Process Performance Measurement driving process management 

To reiterate, few companies currently take a process view of performance 
management. Many manage organizationally and look at financial indicators that 
provide fairly gross level indication of performance or how to improve it. Many 
others have implemented quality programs and attempt to infer performance based 
on statistical variance from industry or other standards. Both are good starts and 
sound approaches to performance improvement, but these and virtually all other 
approaches lack the framework needed to actually see what the data is telling 
management and, further, what action to take to leverage the information. Both are 
good indicators that something is happening, but not of why or how it is happening. 
Even worse, few organizations can actually analyze the operation, redesign the parts 
needed to change the performance numbers, and then build or modify the 
applications needed to implement the changes. 

So, although measurement takes place, the framework needed to understand the 
meaning of the data and then act upon it is missing. As a result, even if the 
information can be properly interpreted, little can be done with the story it is telling 
and little can change quickly enough to make a difference. 

Recognizing that any move to measure performance and then act on the information 
is a good start for companies at early levels of process management maturity, the 
key (again) is to manage expectations according to reality. 

As the company moves to higher levels of process management maturity and thus 
process measurement maturity, it will also move through a different type of BPM- 
support evolution that will lead to the broad-based or strategic use of BPMS tools 
and technologies. BPM — especially a BPMS-supported BPM business operation with 
SOA and web-services-based access to applications and data — changes the picture 
by allowing management to put the data obtained from performance measurement 
approaches and reports into a framework (as discussed in chapter 10, "BPM 
Technology"). This framework is the context for evaluating, at the necessary level of 
detail, the story of the data. 

With this framework in place, it is possible to view the performance information 
that is available in a different way — a way that is based on context. Here the 
upstream and downstream activity is shown and the causes of problems can be 
found. Solutions to improve volume, quality, and customer interaction can be better 
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considered, modeled, simulated to determine results, and then fully built with 
access to legacy applications, business rules, performance measurement, and more. 

Quality measurement vs. performance measurement vs. financial measurement can 
now be applied to process or workflow, either separately or together. Each 
approach to applying measurement provides unique information from the 
perspective of the group requesting the measurement. When combined, this 
information can tell a powerful story: to quote an old proverb, "the whole is greater 
than the sum of its parts." For this reason, it is suggested that the information from 
measures based on these three perspectives and others, if used, be combined and 
reviewed quarterly in a workshop with experts from all measurement perspectives. 
This will provide insights that might otherwise not be available. 

6.3.2 How does Process Performance Management fit in with your 
Business Intelligence Reporting and Management? 


Business Intelligence: Computer-based techniques used to 
identify and analyze information about how the business is 
performing. This includes statistical analysis, trend analysis, 
costand profitability analysis and more. It also includes more 
advanced reporting such as inference- and limit-based alerts 
for both intervention and long-term strategic change. 


The information obtained from performance measurement can be used to augment 
other Business Intelligence (BI) information from a variety of internal and external 
sources. Also, using a BPMS rules engine, this information can be run through 
inference and decision filters to provide both reporting information and 
recommendations on actions. 

For many companies, performance information obtained as part of a BPMS- 
supported BPM operating environment will provide a new type of data to the BI 
reporting capability. It will allow management to look at new data sources (process 
and workflow — cost, volume, quality) and ask new questions on operating 
performance — both historical and current. To drive this reporting, it is suggested 
that BI needs be considered when looking at what data will be obtained and where it 
will come from. (See this chapter’s subsection 6.4.1 for a sample list of information 
that may be considered.) 

When performance information is added to the information available for BI 
reporting, it also allows management to build a BI performance feedback loop into 
performance improvement. Management can use the feedback loop to improve their 
control over responses to information and alerts and to adjust limits placed on 
measurement as the operation improves. This ties the BI reporting into continuous 
improvement and allows management to adjust operating variables (staff, volume, 
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IT support, etc.) and measure the change. In this way, BI becomes a driver in the 
company’s continuous improvement program. 

6.4 Measurement and Management 

Performance measurement is simply data. It tells a story, but the story is 
interpretive. The interpretation is based on the perspective of the person or group 
considering the data and its context, and perspective is what results in different 
interpretations of the same data by different groups. For example, internal and 
external customers of any work may have very different ideas of performance and 
very different ways of looking at the data produced from the performance 
measurement processes that are in place. Among the factors that cause this differing 
perspective are 

• Business objective — differing opinions on why is something being measured 

• Value lever/driver — event/outcome; value to the consumer; importance 

• KPI — standard value to compare against and what that value is trying to say 

• Metric definitions and how something is measured — limits in values and 
their importance in measuring performance. 

While these and many other factors form the basis for opinion and perspective, 
measurement concerns go beyond issues of opinion to acceptance (or not) of the 
way something is measured — the formula the measurement program or person 
uses and the approach taken to ensure quality data and calculations. While the list 
above provides examples of things that cause disagreement over what is being 
measured and what it is being compared against, the real problem is in the way 
things are measured. This is the basis of measurement rejection and dismissal of 
measurement reports. As such, it is critical that everyone involved agrees to the way 
things are measured and that this agreement is reviewed on a regular cycle to 
ensure continued acceptance. 

6.4.1 What should be measured? 

The following are performance and quality measurement categories that should be 
considered. The list is not meant to be all-inclusive; it is meant to promote thinking. 
Specific processes or activities measured will vary by company, process, maturity 
level, and compliance need. 

Operational Performance 

• Process level: 

o Transaction volume 
o Event reaction time 
o Backlog by subprocess 
o Cycle time by event reaction 
o Number of errors in processing 
o Number of exceptions to normal processing 
o Waste — time, material 

o Problems with trading partners and collaborative partners 
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• Workflow level: 

o Transaction volume 
o Backlog by activity — bottlenecks 
o Number of errors by activity and person 
o Number of exceptions to normal processing 

o Number and location of decision and other delays (exits and reentry 
points) 

o Problems with external workforce — sales (agents), claims adjusters, 
offshore services 


Financial 

• Process level: 

o Cost of each subprocess — staff, material, computer chargeback, G/A 
o Cost of goods sold — process with costs of external work — work sent 
to other processes and returned 
o Scrap 

o Savings from a new solution 

• Workflow level: 

o Activity Based Costing 

o Savings from a new solution — stand alone or roll up to the process 
level 


Legal 

• Process level: 

o Legal compliance 

o Compliance reporting — on time and complete 

• Workflow level: 

o Application of union agreement terms 
o Legal compliance — e.g. SOX, HIPAA, Dodd/Frank 
o Measurement to support compliance reporting at the process level 

Problem identification 

• Process level: 

o Handoff issues 

o Edit database quality — duplicate records etc. 
o Audit and inspection results — manual of interim components and 
final products 

o Delays waiting for additional information 

• Workflow level: 

o Handoff quality 

o Data entry edit — rejections by reason 
o Identification of rules that do not work correctly 


Customer Experience 

• Process level: 
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o Customer interaction satisfaction — Interaction with company via 
sales staff, web portal, phone 
• Workflow level: 

o Company error in orders, etc. 

o Problem resolution — phone, email, fax, and other interaction with 
customers to obtain data or correct information 


Quality 

• Process level: 

o Six Sigma, TQM etc. quality monitoring 

o Audit/inspection of product sub-assemblies or components of 
services 

o Audit/inspection of final product — error and rejection 

• Workflow level 

The results of work monitoring and performance measurement will be reports that 
should either generate an action by management or provide information. The 
content of these reports will vary based on what they are trying to measure; 
performance measurement should be unique to the need. However, it may be 
necessary to look at performance management needs in aggregate and identify all 
the data that will be needed, along with sources of the data. The collection and 
storage of this data then becomes an IT issue, but it would be useful to have all the 
needed data in one place to support drill down and flexible reporting. 

6.4.2 Daily monitoring: Dashboards 

Data may be reported in a variety of forms. Some are detailed and some are 
summary. The best form is always related to use. For near-real-time summary 
reporting, dashboards that continuously change to reflect what is being measured 
tend to provide management with a constant view of the operation. When these 
dashboards are supported by intelligence in the form of rules, the reporting can 
provide an analysis that gives managers alerts to growing problems and provides 
recommendations on action that should be considered. 

Any dashboard should be designed to provide a clear picture of a specific part of the 
operation. The focus can be on organization, process, workflow, or almost any part 
of the business. The information shown will evolve as management trades the 
display of less meaningful information for information that is more meaningful at a 
given point in time. The definition, data content, display summary, and creation of 
these dashboards should therefore be made as flexible and easy to change as 
possible. 

Dashboards serve as a starting point for looking at performance and "drilling down" 
into the detail that supports the summary. This drill down can be scripted to allow a 
consistent type of information inquiry (limited flexibility) or ad hoc to allow the 
manager to follow the data in any direction he or she finds appropriate. 
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As with most performance reporting, management needs will vary with the business 
operation’s level of process management and performance measurement maturity; 
however, the use of dashboards to support the collection and reporting of near-real- 
time operational information will become an indispensable tool for measuring 
activity and managing the business operation at both the workflow and process 
levels. 

6.4.3 Measuring against KPIs and benchmarks: efficiency 

Performance is all about meeting or exceeding specific benchmarks, standards, or 
KPIs. These preset indicators provide a type of framework for determining how a 
part of the workflow or process is performing, or how the work in a whole business 
unit or process is being performed. Earlier in this chapter, we presented a list of 
possible areas that should be considered for measurement. That is the easy part. 
Figuring out how to measure is the politically challenging part. The hard part, 
however, is figuring out what to measure against — unless the targets are simply 
guesses or have been defined through manual measurement over time. 

Any measurement must be given context; otherwise it is simply a raw number. The 
context is the evaluation criteria — the KPI, standard, benchmark, etc. Any 
meaningful context can be used in this evaluation. It should be company-specific or 
specific to the process or workflow. The key in defining this context is that it will 
need to evolve as the company evolves its continuous improvement program. (At 
least one would hope that things constantly improve.) As this happens, the 
measurement context should be adjusted to ever tighter specs or limits. 

For many companies, who have limited performance measurement experience or 
who want to take measurement to a new level of meaning, the selection of targets 
should begin with a study on current manual measurement and its limitations. The 
study should look at what should be measured and the standards, KPIs, etc., that 
should be put in place to evaluate against. As with all parts of a valid performance 
measurement capability, the context limits and targets should be built with the 
people who will be measured, and all recommended value targets should be agreed 
upon by both the managers that will be measured and the executive team for the 
business area. 

6.4.4 Inference engines in performance management 

Real-time or near-real-time performance can be monitored using a BPMS. This 
monitoring provides a continuous stream of data from multiple sources. When this 
data is used to drive measurement, it will produce event-related or scenario-related 
results. Here the event or scenario associated with the data can be easily linked to 
the data. This allows the data to be viewed automatically against preset factors that 
define the situation. With this, the BPMS can associate rules to look at the situation, 
look at the data values, and then infer action — or recommend what to do. 

This can also be used to help determine and direct action in a highly volatile, fast 
moving, critical situation, or in highly complex situations to look at the data and the 
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situation and recommend action quickly. In some cases, the response can be further 
refined through management inquiry into the inference engine to add information. 

6.4.5 Trend and other analysis 

Trend analysis, myriad types of financial analysis, and other analysis can obviously 
be built once the data is defined and the technical framework to access it is in place. 
The performance measurement activity should include the needs of executive and 
other managers to look at performance from their individual perspectives. These 
perspectives should be identified and defined based on an analysis of the current 
performance-measurement activities and their overlaps with the analysis and 
reporting needs of the BPM effort. Eventually, the performance-reporting needs will 
be addressed, business area by area and process by process, to provide a 
comprehensive and flexible process-management support environment. 

To find these reporting requirements, it is suggested that the BPM Practitioner meet 
with the IT managers responsible for supporting the business areas and business 
intelligence reporting. These meetings will provide a list of current reporting needs 
and backlogged reporting requests. The BPM Practitioner should then meet with the 
business managers who have responsibility for the work in scope (business and 
process owners) and any other managers who have requested additional or 
different reporting. These meetings will look at the current and future business 
evaluation reporting needs — business operation and strategic improvement. Trend 
and other types of long-term analytical needs will be defined in these meetings. 

As many of these perspectives should be built in as possible, with the perspective’s 
information-analysis defined, data and sources identified, and overlaps with other 
work-management performance-reporting identified, to produce a list of both 
management-related performance data and Business Intelligence data needs along 
with the source databases and systems for each data element. 

In this way, the effort will be able to support the greatest range of identified 
performance reporting needs. This will improve the cost/benefit calculation for the 
effort and for the company’s move to BPM and a BPMS-supported BPM operating 
environment. 

6.4.6 Satisfaction: experience measurement (good and not so good 
experiences) 

Customer satisfaction is hard to measure but critical. In today’s age of instant 
communication, both positive and negative experiences spread quickly all around 
the world. This does influence customer action, and customers respond with their 
pocket books — they can simply go elsewhere to purchase a product. As a result, 
progressive companies are starting to map all customer-interact points and finding 
ways to anticipate customer interactions and drive customer experiences. This is 
still fairly new; what started as a new Customer Relationship Management (CRM) 
concern with a few tools to scan the internet and report on messages for reaction- 
based reporting is now morphing into a more organized "customer experience," 


227 


Copyright ABPMP International 


Chapter 6. Process Performance Management 


"voice of the customer," "patient management" etc. concern that is looking 
proactively at defining and measuring the total customer experience. 

This concern is taking on a different importance as companies come to understand 
that the customer is interested in price — but not at a cost of good service and 
quality. This new understanding or really new appreciation for the customer is 
causing companies to look holistically at the customer and how to win his or her 
loyalty. This includes rethinking the use of offshore call centers, web portals, 
customer service operation (that require the staff to look through multiple 
applications to handle simple problems — if they in fact are ever really handled), and 
more. The goal is to remove all obstacles to a good interaction with the customer. 

But measuring this is hard, since it is opinion-based and requires a more complex 
and comprehensive look at the customer, their level of technical sophistication, their 
needs for simple and predictable activities (like returning an item or adjusting an 
account), and their anxieties, in order to improve the experience. 

This reporting is coming and should be considered when looking at performance 
and how it can be measured. 

6.5 Finding out how to measure performance 

We have looked at what could be measured and how to determine sources of 
information. It is now time to look at how performance can be measured. In many 
companies that do not have a BPMS to help drive performance measurement, the 
activity will need to be a combination of manual counting and feedback with 
information that can be obtained from legacy applications. This reporting will not 
support real-time or near-real-time monitoring or measurement that BPMS offers to 
drive operational management. In the more traditional business operations with 
limited reporting capabilities, the move to performance reporting will rely on the IT 
department’s ability to devote the time and resources needed to create a 
comprehensive performance monitoring and measurement capability. If this is not 
available, the analysis and design that have been discussed will not provide the 
ability to create this program. 

The remainder of this chapter assumes that a BPMS operation is in place in some, if 
not all parts of the process, and that the BPM practitioners on any project have 
timely access to IT programming, data management, and other IT support, as well as 
the priority to have work performed and delivered in a timely manner. Again, if this 
is not available, it will be necessary to either build this support or modify the 
schedule to account for minimal IT support. 

In addition to the need for automated support, it will be necessary to look at the 
reporting needs and tie them back to the workflow in a business unit and/or the 
points in the process where the performance information can be measured. 
Individual monitoring/ information collection will take place at these points. The 
reporting performed at these points will be defined and the formula and data 
required will be identified. This data collection will drive reports at any level, where 
the data can be combined to form a broader review of the business. 
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Monitoring and measurement approaches such as Six Sigma and Activity Based 
Costing will drive the way activities are measured and the type of information 
collected. These approaches can be applied at any level of activity measurement — 
process to workflow to task. 

Most important is that the process professional base any monitoring or 
measurement on approaches that are understood in the company and supported by 
management. 

6.5.1 Designing a performance management process 

The performance management process is designed around the information needs of 
different managers in the process or workflow, depending on the level of reporting. 
It is also directly related to the company’s level of process management maturity. 
Only those things that are understood and supported with management technique 
and data availability can be measured. 

Realistically assessing these abilities is the foundation for both monitoring and 
measurement. However, everyone must start someplace. It is important to recognize 
that companies or managers who are new to performance measurement or 
advanced measurement will go through an evolution as they learn what is possible 
and what is most needed. Often this learning curve begins with a lot of unnecessary 
monitoring and measurement. This is evident over time by what is discarded as 
management focuses on what is helpful. 

This is important in setting expectation and in designing a performance 
measurement process that is meant to change as management learns more about 
process and workflow performance measurement and what information and 
reporting mechanisms are available. In this journey, it is critical that any 
measurement and reporting capability be flexible and that no one expects it to be 
either accurate or optimally beneficial to them from the start. Success in this activity 
is thus based on trial and improvement over time. This is important in both 
expectation setting and in defining the costs of making this transition to 
performance measurement and evaluation. 

The actual performance measurement/reporting/evaluation/response 
(performance management) process will thus be fairly unique to each process and 
each workflow. This is necessary to support the needs of the management at all 
levels in the business. Following the interview with company managers suggested 
above, the BPM practitioner will need to create a performance management 
approach with initial measurement points/formula/KPIs. This will then be built into 
the business operation using additions to the BPMS-based operating environment 
or technical links/interfaces/etc. to the legacy and new supporting applications. 

Use will show needed changes in the measurement activity and begin the evolution. 

The ability of the company to support any performance 

monitoring/measurement/evaluation will directly depend on its ability to obtain 
good data (near-real-time) from both the workflow or process flow and the 
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legacy/licensed applications that support the business. In some cases, manual 
auditing and counting may still be needed — especially if a BPMS is not the base of 
the business operation. Performance reporting may thus be limited, and it may be a 
mix of automated and manual reports. Again, this is tied to the company’s level of 
process management maturity and automated application support. It is also directly 
tied to the ability of the company to obtain and move information from multiple 
sources and then provide it in a form that can be used for evaluation. The limits IT 
capability places on performance measurement must thus be identified as early as 
possible in the creation of the company's journey to performance management. This 
will help define reality and set the roadmap to improved 
monitoring/measurement/evaluation as part of a continuous improvement 
program. 

6.5.2 Determining KPIs and Standards to measure against 

Standards, KPIs, and other performance targets will first be set based on current 
targets — if they exist. If these targets do not exist, the business areas, internal audit, 
legal, etc., should be contacted to look at needs and ways to find the initial targets. 
This may include union contracts, manual counts over a given statistically relevant 
time, industry models, associations, and so on. 

Assuming the process or workflow managers have performance targets, it will be 
necessary to identify the reasons for these targets. If the manager cannot define the 
target and justify why it is the target, the target should be put aside until a manager 
can determine why it is needed. New targets should be classified as "in trial" and 
measurement against them should be temporary, until the reporting and its use 
show the value of the measurement area and its defined limits or target. 

It should be noted that as performance improvements are implemented, the target 
values should be reviewed and made to reflect the improved business operation. If 
this is done, the target values will become tighter as the operation continues to 
become closer to optimal. 

The measurement areas and their KPIs, standards, etc., should all be part of an 
evolving program where use and value determine longevity. If an area is not of high 
value, it should either be changed to make the measurement and targets high value 
or it should be dropped. This type of monitoring and measurement program forces 
the continuing review of measurements and targets against value to the company. In 
this way, measurement areas and their targets remain useful and evolve with the 
business. 

The continued evaluation of the performance measurement "system" (business 
activity, measurement approach, measurement formula, performance targets) 
should be formal, and the review of all measurement areas and values should be 
made in workshops where all managers who use the performance reports will have 
input into the continued use of the measure and changes to target values. Any 
changes should be agreed upon by all who use the information. This formal change 
process will help ensure that the right things are measured and that the 
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performance measurement program delivers the right information, to the right 
place, at the right time. 

6.5.3 Determining measurement approaches and formula 

Just as important as determining what to measure, when to measure it, and what to 
evaluate the measurement against, is the need to determine how it will be 
measured. The measurement may be simple manual counting driven by a formula 
that says the count will be divided into groups for X, Y or Z value in a given field. It 
may be a need to audit the values of every 10th transaction. The list of measurement 
directions (formula for measuring) is endless and will be unique to every company, 
department, process and workflow. The formula itself will evolve and is not the 
important takeaway from this section. What’s important is that each measurement 
area and its measurement(s) be directed by a formal, reviewed, approved formula. 

Without this, the results of any measurement are open to question, debate, and 
rejection. This can only be avoided when the measurement area, measurement 
targets, the measurement approach and the measurement formula have all been 
vetted and formally approved by those who will use them. 

As with the other areas of performance measurement, the formulas should be 
considered as temporary and evolve as the business evolves. This evolution should 
be formal and only take place in the performance measurement management 
workshops. 

6.6. Building a Performance Measurement Capability 

The hardest part of building any performance measurement capability is politics. 
Few managers want to be measured: resistance will be high, and disagreements can 
be expected over what will be measured and how. Care must be taken with this, 
because it is easy to find objections, or for managers to lack time for any type of 
measurement. Executive sponsorship is thus critical. It must be active (participate in 
meetings, communicate through memos, etc.), it must be constant, and it must be 
visible. This is the part that drives participation. 

The second biggest hurdle is the ability of any company to support process 
performance measurement. Many companies really do not understand process in 
the business or production parts of the company. Few companies really understand 
all their processes, how they interact with one another (the internal and external 
activities), and how the work that is done is divided among business units. This 
understanding is important in creating a performance measurement capability that 
provides useful information. 

At times this second hurdle becomes a movement killer. Expectations must not be 
set too low or too high. They must be realistic — especially in companies with a 
negative view of IT support. If IT cannot or will not provide the level of support that 
is needed, the effort will lose credibility and die. 
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For these and other reasons, it is important to look at performance measurement as 
a journey and to plan that journey. It should be orchestrated and managed formally 
by a committee of managers who will be affected in each process. Companies should 
consider creating a performance management governance group to set the approach 
and monitor the way performance measurement is managed by the process 
management groups. The governance group would be responsible for defining how 
performance measurement will be approached (especially in a BPMS-supported 
business operation), how it will be controlled for quality, and how it will evolve (e.g., 
manager workshops and formal approval). The group will need to serve as the 
central interface between the business and IT, to help with IT planning and avoid 
conflicting IT interaction, and it can also be part of a BPM Center of Excellence 
(COE). 

6.6.1 The role of BPMS technology 

BPMS-based BPM operating business environments will be able to provide a wide 
variety of performance reporting information for both near-real-time and after-the- 
fact reporting. However, this reporting will need to be defined in the BPMS and all 
external but linked applications. This includes applications that look at the flow of 
information, such as Six Sigma monitors and applications that count. 

6.6.2 Legacy application and business reporting 

It is unlikely that IT groups will be prepared to support process performance 
measurement and reporting. Applications will generally stand alone for 
performance reporting: even though they are interfaced for business support, the 
reporting needs may require a different interfacing. 

6.6.3 Building new reporting is a journey 

Because it involves working together with IT, legal, finance, executive management, 
and the managers in the business units that support workflow. 
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Process Performance Management Section II 
Introduction 

Process Performance Management involves both an understanding of what to 
measure and how to measure it. This chapter is thus divided into two basic 
sections — what to measure and (basically) how to measure performance. In 
this second part of chapter 6, we will focus on how performance can be 
measured in a BPM-based operation. 

World-class organization 

Loss 



On target with minimum product/service Maximum value generated with minimum 
variability use of resources 

Process Performance Management plays a critical role in aligning the organizational 
goals to the voice of the client through stable and predictable processes. Variation in 
quality, duration, delivery, and cost exists in all processes. Understanding, 
managing, and gaining control over the variation are keys to providing world-class 
products and services. A BPM CBOK must bring to light the range of techniques 
available to support process performance management. This chapter will address a 
representative collection of such techniques. 

6.7 Importance and benefits of performance measurement 

The importance of measuring the performance of a process cannot be overstated. 
Management and quality experts from W. Edwards Deming to Peter Drucker have 
declared that "if you cannot measure it, you cannot manage it." This statement holds 
true, and every business should invest time and resources to improve a process if 
they don’t already know what they have to measure in order to improve. 

Measurements are the basis for detecting deviations from acceptable process 
performance and results. Process performance can be measured by the attributes of 
products or services that the process produces, such as reliability, capacity, 
exception, response time, and service complexity. Process performance can also be 
measured by the attributes of the process itself, such as defect-removal 
effectiveness, effort, and cycle time. These measures can reference the actual 
performance of the process and predict future behavior and output. 
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Process performance managers should find the right balance for key process 
performance indicators, while contributing to the enterprise’s long-term strategic 
business plan. Performance indicators such as client satisfaction, turnover, cost 
control, and risk management can be monitored through dashboards by showing 
current values compared to target values. 

Let’s illustrate the importance of performance measurement with an example. 

Assume that an organization is experiencing a loss in market share. Their current 
market share is 68%, but their goal is to have an 80% share. For simplification, this 
is a mature industry and the organization and its competitors are not really 
interested in new products, but rather in taking market share from one another. 

Market share is what the organization uses to measure itself in terms of revenue 
growth, but aside from market share, what is the reason, in process terms, why the 
organization is having difficulty? If the Order Fulfillment process is reviewed, we see 
that there has been a drop in client satisfaction, but why? After some process 
analysis, it is discovered that the current order cycle time is 9 days. In other words, 
it takes the organization 9 days to accept, commit, order, and then ship to the client. 
In a competitive global economy and in this kind of industry, that type of 
performance is not acceptable, especially to those clients who can easily get the 
same product from a competitor — hence the drop in market share. 

The next question is, what is causing such a delay in the order cycle time? After 
further analysis of the process, it is discovered that the sales staff are entering in the 
client orders late and there are a lot of errors or incomplete forms for client orders. 
From l%to 10% of forms are incomplete and order accuracy is only 83%. 
Furthermore, sales representatives are entering their orders once a week instead of 
on a daily basis. The expected results are not being achieved and it is impacting 
different levels of the process. More importantly, it is impacting the client. 

This example also illustrates that not everyone in the organization has a complete 
picture of what is happening. The Vice President of Marketing views this issue as a 
market share problem. The Vice President of Supply Chain views this as an order 
cycle time problem, and finally the Vice President of Sales views this as an issue with 
the accuracy and timeliness of the sales order forms. None of them understands the 
other’s perspective. The CEO only knows that revenue is not growing, so neither are 
profits. While each person may have a metric for which they are accountable, it is 
unlikely they understand the extent of the cross-functional process that links them 
all together from a process performance perspective. What makes it worse is that 
they are function-focused, which means that they will attack the symptoms 
independently. 

Figure 48, adapted from Geary Rummler, illustrates the cross-functional "Order to 
Cash" process from an enterprise perspective: 
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Enterprise Issue 

“Loss of Market Share” 


Process Issues 


(Order Fulfillment Process) 


Desired Results: 

• Market Share of 80% + 
Current Results: 

• Market Share of 68% 


“Drop in Customer Satisfaction" 


Activity Issues 

(Order Fulfillment Process) 

“ Inaccurate , late Order Forms" 


Desired Results: 

• Order Cycle Time of 1 day 
Current Results: 

• Order Cycle Time of 9 days 


Desired Results: 

• Zero Incomplete Order Forms 

• 100% Accurate Orders 

• Orders Submitted Daily 


Current Results: 

• Between 1 -10% Incomplete 
Order Forms 

• 83% Accurate Orders 

• Orders Submitted Weekly 


Figure 48. Order-to-cash process (Source: adapted from Geary Rummler) 


This happens more often in those organizations that put importance on process and 
associated process performance metrics rather than financial metrics alone. 

6.8 Key process performance definitions 

Measurement, metric, and indicator are terms often misinterpreted and mistakenly 
used interchangeably. 

Measurement is directly related to the quantification of data 
(or data set) in an acceptable standard and quality (accuracy, 
completeness, consistency, and timeliness) 


To illustrate this, take "ten inches" as an example of measurement. Inches are the 
standard and "ten" identifies how many multiples or fractions of the standard are 
being verified. 
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Metric is a quantitative measure that a system, component, or 
process has of a given attribute. Metric represents an 
extrapolation ora mathematical calculation of measurements 
resulting in a derived value 


For instance, number of defective products by the total number of products 
produced (defect number / total production) or two errors identified by users in the 
first eighteen months of activity (number of errors / time). Efficiency and 
effectiveness, however, are generally a function of one or more of the four 
fundamental measurements (time, cost, capacity, and quality), so they are more 
related to metrics than to measures. 


Indicator is a representation of a measurement or metric in a 
simple or intuitive way to facilitate its interpretation against a 
reference or goal 


An example of indicator would be "green indicator is good, red indicator is bad." 
Metrics can be classified into three categories: 

1. Product metrics: Describe the product characteristics such as size, 
complexity, design features, performance, and quality level. 

2. Process metrics: Describe process characteristics such as customer 
satisfaction, Mean Time To Failure (MTTF), effectiveness of defects removal. 

3. Project Metrics: Describe project characteristics and execution. Examples 
include resources allocation, cost, time, and productivity. 

Process Performance Indicator (PPI) derives from process goals and allows the 
process owner to control process performance in terms of time, cost, capacity, and 
quality. There are twelve characteristics of effective management through PPI: 


1. Alignment 

A PPI is aligned with corporate strategies and objectives 

2. Accountability 

Every PPI has a process owner or process manager who 
is accountable for its definition, monitoring, and control 

3. Predictive 

PPI could easily provide a way to trace patterns of 
process performance 

4. Actionable 

PPIs are populated with timely, actionable data so 
process owners or process managers can intervene to 
improve performance effectively 

5. Few in number 

PPIs should focus on select high-value information or 


236 


Copyright ABPMP International 


Chapter 6. Process Performance Management 



on the overall effectiveness of the process 

6. Easy to 
understand 

PPIs should be straightforward, not based on complex 
metrics that managers do not know how to influence 
directly 

7. Balanced and 
linked 

PPIs should balance and reinforce each other, not 
compete and confuse 

8. Transformative 

A PPI should change the way the organization evaluates 
itself 

9. Standardized 

PPIs are generally more effective when based on 
standard metrics so they can be integrated across 
dashboards, throughout the organization, and used for 
benchmarking within and across industries 

10. Context-driven 

PPIs put performance in context by applying targets 
and thresholds so process managers can gauge their 
progress over time. 

11. Reinforced 

The impact of PPIs may be enhanced by attaching 
compensation or incentives to them 

12. Relevant 

PPIs may gradually lose their impact over time, so they 
must be reviewed and refreshed when necessary 


Table 19. Source: www.techrepublic.com (adapted) 


The overall purpose of understanding process performance indicators is to enable 
managers to contribute to improving or changing a process as part of process 
performance management. 

An application encompassing the definitions of measurement, metric, and indicator 
is when project schedule estimation is assessed for accuracy. Two important 
measures to determine the accuracy of project schedule estimation are Actual 
Project Duration and Estimated Project Duration. Apply measures by getting Actual 
Project Duration and Estimated Project Duration. Metric is when the Schedule 
Estimation Accuracy (SEA) is calculated based on the formula SEA = Actual Project 
Duration / Estimated Project Duration. An Indicator would be a representation of 
SEA in percentage instead of an absolute number so that interpretation and decision 
making are made easy. SEA = 1 represents 100% accuracy estimation, so SEA 
indicator = 100%. If SEA is a number between 0 and 1, then just represent SEA as a 
percentage to get SEA indicator for overestimation, e.g., for SEA = 0.5, then SEA 
indicator = 50% (50% accuracy). If SEA is a number greater than 1, then raise SEA 
to the power -1 (SEA-1) and multiply by -1 to get SEA indicator for 
underestimation, e.g., for SEA = 2, then SEA indicator = 2-1 * -1 (-50% accuracy). See 
Table 20 below. 
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Object 

Measure 1 

Measure 2 

Metric 

Indicator 

Project 

• Actual Project 

• Estimated Project 

• SEA (Actual/ 

. SEA Indicator 


’ Duration 

Duration 

' Estimated) 

; (+%) 

PI 

. 90 days 

. 100 days 

. 0.90 

. 90% 

P2 

■ 187 days 

150 days 

- 1.25 

■ -80% 

. Pi 

. 450 days 

. 195 days 

. 2.31 

. -43% 

. Pn 

. 180 days 

. 180 days 

. 1.00 

. 100% 


Table 20. Measurement Sample 


All processes can have a measurement associated with the work or output of the 
process that is performed. These measurements are based on four fundamental 
dimensions: time, cost, capacity, and quality. 

6.8.1 Time 

Time is associated with process duration. Cycle Time measures the time it takes 
from the start of a process to its completion in terms of the output. Examples of time 
dimension are 

• Delivery Performance, Request Date 

• Order Fulfillment, Lead Time 

• Product Development, Lead Time. 

6.8.2 Cost 

Cost is a value (normally monetary) associated with a process. Cost can assume 
different perspectives; for example, resource cost is a measurement of the value 
associated with the resources (human or non-human) required to complete a 
process, and opportunity cost is the value that is lost from the process by not getting 
the resultant output of the process. Examples of cost dimension are 

• Sales Cost 

• Manufacturing Cost 

• Logistics Cost 

• Inventory Supply Days 

6.8.3 Capacity 

Capacity is an amount or volume of a feasible output associated with a process. An 
example would be the number of transactions associated with a process. Capacity 
usually has a revenue connotation associated with it. If a manufacturing line could 
improve the yield (reduce variation) of the line, then in essence the number of good 
products that could be sold to clients would increase, thereby increasing the 
revenue to the manufacturer. 
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Capacity can also have a throughput connotation associated with it. An example of 
this would be when, in a manual process, sales orders are manually entered into a 
software application by sales people. The number of sales orders processes per hour 
would be limited by the number of people and how many orders could be processed 
during each hour (preferably without errors). If orders could be processed through 
a browser interface directly by the client into the order management system, then 
the number or orders processed per hour would be limited by the number of 
concurrent clients on the website. However, it would be more in quantity than if 
orders were processed by individual sales people. Examples of capacity dimension 
are 

• Client Dollars per Order (Wallet Share) 

• Client Growth Rate 

• Market Share 

6.8.4 Quality 

Quality is usually expressed as a percentage of actual to optimal or maximum; in 
process terms, however, it can take many forms. For example, variation is a quality 
metric of the amount, extent, rate, or degree of change and is generally expressed as 
the difference between the actual and target or expected result. Error or defect rate 
is an example of variation in the metric of errors associated with the output of a 
process. Satisfaction, on the other hand, is a quality measurement usually associated 
with a service level expectation on the part of the customer. Examples of quality 
dimension are 

• Product Launch Variance 

• Forecast Accuracy. 

6.9 Monitoring and controlling operations 

Not only is it important to measure processes, it is even more important to 
continually measure, monitor, and control them in order to achieve the desired 
results. In that respect, basic process performance management is more of a journey 
than a destination. Once the Order Fulfillment process is documented in its entirety 
and the initial process metrics are identified, collected, and managed, the 
organization can monitor for changes that will ultimately impact the market share of 
their product. 

“Discovering that a process is out of control is not a terrible 
event. It should not be hidden from supervisors, managers, 
auditors, quality control experts, or, most important, 
customers. In a sense, it is an event that should be celebrated 
because it gives the process owner an opportunity to improve 
the process.” Robert Hoyer & Wayne Ellis, 1996 
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Some aspects of using indicators must be taken into account while monitoring and 
controlling operations. It is possible to create indicators based on decision-making 
models: 


Step 1 

Define the problem to which the indicator 
applies. Managers very often act without having a 
thorough understanding of the problem to be 
solved, leading them not to solve the problem. 
This is a common problem on BSC indicators 
adapted to BPM models. Managers frequently 
make mistakes by (a) defining the problem in 
terms of a proposed solution, (b) failing to notice 
a major problem, or (c) diagnosing the problem 
by its symptoms. The goal of good indicators 
should be to solve a problem, not to simply 
eliminate its temporary symptoms. 



Step 2 

Identify the criteria for indicators; most decisions 
require the achievement of more than one goal. 



Step 3 


Assess the criteria for indicators. Different 
criteria will have different importance. 



Step 4 


Get to know about relevant alternatives. An 
indicator should generate possible courses of 
action. 
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Step 5 

Sort out each course of action based on each 
criterion. How well each course of action meets 
each of the defined criteria? Often, this is the 
most difficult part because it commonly requires 
a foresight into future events. 



Step 6 

Map the alternatives and choose the best one 
using indicators. 


Table 21. Six steps in determining problem response 

Following the six steps in the table above can lead decision makers to (1) define the 
problem, (2) identify all the criteria, (3) assess the criteria according to their 
preferences, (4) know relevant alternative actions, (5) evaluate each alternative 
based on each criterion and (6) map the alternatives accurately and choose the 
highest perceived value. 

While determining the best response to a problem, the team should formally define 
the considerations that should be included in the decision process. This list of 
considerations should include the obvious and relevant-but-not-so-obvious factors. 
This list should grow over time, with the addition of new considerations, and form a 
type of decision consideration standard. See Table 22 as a starting point. 


Considerations 


How to avoid 


The more information, the better 


Consider the vital few indicators and 
avoid the trivial 


What really count are money and profit 


Consider that profit is a resulting 
indicator dependent on the overall 
organizational performance 


They rely only on controlling 
production processes 


Establish a tree of indicators so as to 
consider value-added processes 


All relevant indicators should be used 
to evaluate performance 


■ Check if an indicator, although adequate 
for a particular process, leads to 
! behavior that undermines 
! organizational strategy 

Table 22. Pitfalls in establishing indicators (source: FNQ) 
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While the importance of understanding the process cannot be emphasized enough, 
monitoring and controlling performance of the process is what makes the difference 
in the business environment. As business changes, so will the desired performance 
of the process. The process itself will have to change in order to achieve the desired 
performance, but this cannot be achieved unless the process and the performance of 
the process are monitored and controlled. 

6.10 Alignment of business process and enterprise performance 

Enterprise performance and corresponding measurements are best expressed with 
respect to satisfying client needs and expectations. The example discussed in Figure 
48 was centered on the Order Fulfillment (Order to Cash) process; however, all 
examples of enterprise performance metrics are extrapolations of Time, Cost, 
Capacity and Quality foundations. Some examples of cross-functional processes that 
drive enterprise-level metrics are: 

• Order to Cash 

• Procure to Pay 

• Campaign to Quote 

• Plan to Fulfill 

• Manufacture to Distribution 

• Incident to Resolution 

The traditional approach consists of translating the goals into action plans for each 
major operational or support department. However, this approach has the 
disadvantage of producing fragmented and partial (i.e., related to each individual 
department) plans, leading to difficulty in predicting which action plan will 
eventually bring about the expected result. 

It is important to note that the cross-functional processes will impact more than just 
one enterprise-level process. For example, Plan to Fulfill will impact Delivery 
Performance, Request Date, and Order Fulfillment Lead Time. 

When different process transformation methods (Lean, Six Sigma, Reengineering) 
are used, it is important to understand whether the method will address the cross- 
functional process or just a subprocess within the cross-functional process or even 
an activity within a subprocess. 

In Figure 49 below we can also see that different approaches such as Business 
Process Reengineering and Business Process Improvement apply differently at 
different levels in the process-to-task breakout model. The different approaches 
thus should be aligned to the need. In the model, the Unit title should be analogous 
to the ABPMP use of subprocess. 
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Modest 


Improvement Goals 

Cost, Benefits, Risks 


Significant 

> 


Scope 


Enterprise Wide 1 ' 


Function 


Local 



i ' Fundamental 


Incidental 


Degree of 
Enabler Change 


Role of 
Information 
Technology 


Symbolic Required Methodology Rigor 

& Governance 


Intense 


Management Involvement 


BPI - Business Process Improvement 


BPR - Business Process Reengineering 


Source: Adapted from Process Renewal Group 


Figure 49 


Although there is not yet a hierarchy of metrics that links a process to enterprise- 
level operational performance, there are enough linkages between the cross- 
functional processes and enterprise-level metrics to give BPM practitioners a good 
foundation to improve the right processes within the enterprise. 

The Balanced Scorecard’s process perspective creates a strategic alignment by 
linking an organization’s performance objectives with the supporting processes. The 
objectives of reducing costs, improving productivity, developing market share, and 
maximizing customer satisfaction and profitability can lead to identifying the 
processes essential to their achievement. Thus, the dimensions of time, cost, 
capacity, and quality turn into indicators that are fully aligned with financial and 
customer strategies. 

6.11 What to measure 

What to measure in process performance management has been a mystery to some 
and a dilemma for others. The best way to understand what to measure in a process 
is to first understand the expected result. 

The information required for measuring the dimensions of a process can be 
obtained at both the input and output of the subprocess as well as at the beginning 
and end of the overall process for service-level satisfaction. Metrics such as error 
and defect rates are examples of these quality-based metrics. 

Information required for measuring the cost dimension is usually based on the 
resources needed to perform the process itself, although the opportunity cost can 
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also come from the output information. Capacity information comes from the output 
information of the process. Time-based dimensional metric information is obtained 
from the entire process. 

6.11.1 Process Performance Methods 

There are two very common mechanisms for measuring a process. The first is 
manual: that is, collecting data by hand and either drawing it on paper or entering it 
into a spreadsheet or modeling tool. The second is automation using leveraging 
tools such as Business Process Management Suites, enterprise software modeling 
tools, Business Activity Monitors, or similar tools. All of the various methods used 
today have software tools associated with them. 

There are several common methodologies used by BPM practitioners and only three 
are mentioned here. Value Stream Mapping, Activity-Based Costing, and Statistical 
Process Control are three methods for measuring process performance. The 
purpose of this section is not to recommend one over another, but simply to point 
out that there are methods that can be used to monitor and control processes, each 
with their own characteristics and purposes. 

6.11.2 Value Stream Mapping 


Value Stream Mapping is a Lean mapping technique used to 
visualize the value stream of a process. 


By locating the value-creating processes next to one another and by processing one 
unit at a time, work flows smoothly from one step to another and finally to the 
client. This chain of value-creating processes is called a value stream. A value stream 
simply consists of all the things done to create value for the client. First, follow a 
product’s production path from beginning to end and draw a visual representation 
of every process in both material and information flows. Second, draw a future-state 
map of how value should flow. 

Below is a diagram (Figure 50) of the 7 wastes identified in Lean Value Stream 
Mapping. 
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Waiting: Non- work time, queue 
time, waiting for approval 


Transportation: Wasted time and effort 
to move things within a process or 
between processes 


Motion: Poor planning and 
organizational layout often 
causing motion waste 


► 

Overproduction: 

Producing more than is 
needed, before it is 
needed 



Defects: Something 
unacceptable by the client, 
rework or repair 


Inventory: Typified by stock or 
materials that are not being used in 
the process or current activity 


t 


Over processing: Doing more 
work than is necessary to add 
value to the customer 


Figure 50. The 7 Wastes, Lean Value Stream Mapping 


An important aspect of process performance management is the concept of adding 
value. This concept has its roots in Deming and Juran. Briefly stated, an activity is 
value adding when 

• It is required to generate the output required by the client. 

• The client is willing to pay to generate a process output. 

• Quality and consistency of the component resources or output must be 
maintained. 

• Circumstances may impact process continuity. 

In services, additional value occurs when it enhances client experience even when it 
does not contribute directly to the specific service, e.g., the personal greeting and 
attention provided in a hotel front desk is a value added even though it is not 
directly related to providing the room. Bottom line is that the activity does 
something that is perceived as having added value to the client. Understanding 
whether an activity adds value or not is important when improving a process and 
deciding whether to keep or eliminate a process or subprocess. 

6.11.3 Activity-Based Costing 


Activity-Based Costing is a methodology that assigns costs to 
activities rather than products or services. 


The reasoning behind Activity- Based Costing (ABC) is that there is no accounting 
distinction between costs and expenses: everything that is consumed in an 
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organization is referred as a "cost object." The relationships between cost objects 
and activities and between activities and resources are defined as cost drivers (see 
Figure 51). 



Figure 51. Cost objects and activities 

ABC does not eliminate or change costs; it provides data about how costs are 
actually consumed in a process. Activities consume resources. This consumption 
drives cost and either efficiency or inefficiency. Understanding this relationship is 
critical to managing overhead. ABC is used to discover opportunities for cost or 
efficiency improvement and focuses on overhead. ABC traces, rather than allocates, 
each expense to a particular cost object. 

The ABC method makes indirect expenses direct. It provides activity frequency and 
cost information for comparing activities before and after process improvement. It 
reveals what will happen if a project is not carried out (the do-nothing scenario) and 
which processes provide value (are needed to attract and retain clients or will result 
in operational savings). 

ABC is normally used when overhead is high, cost of errors is high, the process is 
shown to be inefficient, and the competition is stiff. 

6.11.4 SPC— Statistical Process Control 


Statistical Process Control deals with the collection, 
classification, analysis, and interpretation of numerical facts or 
data. Through the use of mathematical theories of statistics, 
statistical process controls impose order and regularity on 
aggregates of disparate elements. 


All work occurs in a system of interconnected processes, and variation exists in all 
processes. Variation may occur as a natural variation due to the nature of the 
process or variation due to some business or technical pattern. Statistical Process 
Control (SPC) is used to understand and reduce or eliminate variability in processes 
that are unstable due to error rates and/or inefficiency. This reduction in process 
instability will improve the process. SPC focuses on the X’s (inputs) that drive the Y 
(output), determining which processes are primarily responsible for driving the Y's. 
SPC then focuses on those primarily responsible processes for improvement. 

SPC is recommended for use when high rate of error or inconsistency of outputs is 
verified. 
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6.12 The voice of the process 

“The control chart is the process talking to us.” Irving Burr, 
1953 


Process performance can be affected by attributes of common entities such as 
people, training, procedures, tools, facilities, material, energy, money, time, policies, 
goals, constraints, laws, rules, and regulations. 

When an organization commits itself to providing products or services to meet 
customer requirements and business goals, quality standard, schedule, and cost 
must be controlled if the process is to be considered capable of providing the 
desired outcome. By bringing a process under statistical process control for a 
sufficient period of time to detect the source of deviation, the errors or inefficiencies 
can be corrected and a capable process can be attained. Therefore, the process must 
display a reasonable degree of statistical control to be considered capable of 
achieving the desired outcome. 

Various analytical methods exist to understand and control process variation. These 
include 

• Exploratory data analysis 

• Bayesian statistics 

• Regression analysis 

• Discrete event simulations 

• Reliability analysis techniques 

• Non-parametric analysis 

• Analysis of variance 

• Control charts 

There is plenty of specialized literature to support further reading on each of the 
above statistical control methods; however, the critical importance of control charts 
demands emphasis. Control charts, also known as Shewhart charts, represent a 
powerful and commonly used technique for determining when a business process is 
in a state of statistical control. There are different types of control charts that can be 
used to plot process behavior and determine the voice of the process: 

• Average (X-bar) and range (R) charts 

• Average (X-bar) and standard deviation (S) charts 

• Individuals and moving range (XmR) charts 

• Individuals and median moving range charts 

• Moving average and moving range (MAMR) charts 

• c charts 

• u charts 

• Z charts 
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Let’s show how an XmR chart (see Table 23) for continuous data works and how it 
could be used for investigating process variability. For example, an oil well produces 
crude oil year-round (24 hours a day by 7 days a week by 365 days a year). Every 
day, the Field Supervisor on duty registers the extraction of the day of each well in a 
table. How can we confirm if the production process has been stable and running 
continuously? Process performance can be quantified by measuring attributes of 
products produced by the process, so a Control Chart can plot process attributes 
values that have been observed during a period of time. 


Day 

Crude Oil 

Extraction 

(B/DxlOOO) 

mR 

UCL 

CL 

LCL 

Day 1 

62 


81,5 

60,7 

40,0 

Day 2 

69 

7,0 

81,5 

60,7 

40,0 

Day 3 

51 

18,0 

81,5 

60,7 

40,0 

Day 4 

57 

6,0 

81,5 

60,7 

40,0 

Day 5 

66 

9,0 

81,5 

60,7 

40,0 

Day 6 

60 

6,0 

81,5 

60,7 

40,0 

Day 7 

59 

1,0 

81,5 

60,7 

40,0 

Day 8 

58 

1,0 

81,5 

60,7 

40,0 

Day 9 

62 

4,0 

81,5 

60,7 

40,0 

Day 10 

51 

11,0 

81,5 

60,7 

40,0 

Day 11 

58 

7,0 

81,5 

60,7 

40,0 

Day 12 

69 

11,0 

81,5 

60,7 

40,0 

Day 13 

61 

8,0 

81,5 

60,7 

40,0 

Day 14 

53 

8,0 

81,5 

60,7 

40,0 

Day 15 

39 

14,0 

81,5 

60,7 

40,0 

Day 16 

70 

31,0 

81,5 

60,7 

40,0 

Day 17 

73 

3,0 

81,5 

60,7 

40,0 

Day 18 

59 

14,0 

81,5 

60,7 

40,0 

Day 19 

52 

7,0 

81,5 

60,7 

40,0 

Day 20 

53 

1,0 

81,5 

60,7 

40,0 

Day 21 

67 

14,0 

81,5 

60,7 

40,0 

Day 22 

63 

4,0 

81,5 

60,7 

40,0 
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Day 

Crude Oil 

Extraction 

(B/DxlOOO) 

mR 

UCL 

CL 

LCL 

Day 23 

70 

7,0 

81,5 

60,7 

40,0 

Day 24 

61 

9,0 

81,5 

60,7 

40,0 

Day 25 

60 

1,0 

81,5 

60,7 

40,0 

Day 26 

65 

5,0 

81,5 

60,7 

40,0 

Day 27 

71 

6,0 

81,5 

60,7 

40,0 

Day 28 

60 

11,0 

81,5 

60,7 

40,0 

Day 29 

61 

1,0 

81,5 

60,7 

40,0 

Day 30 

62 

1,0 

81,5 

60,7 

40,0 


Table 23. XmR chart 


Where: 


Item 

Description 

Formula 

mR 

Moving range 

Difference between data for day X and data for day X- 
1 

UCL 

Upper Central Line 

CL + 2,66 * mR 

CL 

Central Line 

Average number of the collection of data 

LCL 

Lower Central Line 

CL - 2,66 * mR 


Then: 


CL 

60,7 

mR = 

7,8 

UCL = 

81,5 

LCL = 

40,0 
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Crude Oil Extraction Well X 



Figure 52. Data summary 

When this is charted, it produces Figure 52. 

At least 4 effective tests, called run tests, can be used for detecting unusual patterns 
in the process outcome (see Figure 53): 

Test 1: A single point falls outside the 3-sigma control limits (UCL, LCL) 

Test 2: At least two out of three successive values fall on the same side of, 
and more than two sigma units away from, the Centerline 

Test 3: At least four out of five successive values fall on the same side of, and 
more than one sigma unit away from, the Centerline 

Test 4: At least eight successive values fall on the same side of the Centerline. 


Crude Oil Extraction Well X 



Figure 53. Patterns in the process measurement 

These tests assume that successive observed values are statistically independent so 
natural variation is symmetric about the mean. In our example above, run tests can 
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highlight process variability on Day 15 through Day 17, signaling that something 
happened to the process that should be investigated. 

Walter A. Shewhart (1931) categorized two sources for process variation: 

Common cause variation: Due to natural and inherent characteristics of the 
process, variation occurs randomly around the mean. Synonyms for common 
cause are non-assignable cause or natural patterns. 

Assignable cause variation: Due to unexpected factors or occurrences that 
hinder process performance and affect process outcome. A variation occurs 
from the mean or persistently on one side of the mean. If it represents a 
problem, it should be addressed and eliminated. Synonyms for Assignable 
cause are special cause or unnatural patterns. Examples: operator falls 
asleep, equipment malfunction, power surges, lack of raw material stopping 
production lines, workers on strike, or climate conditions preventing 
workers from carrying on activities. 

[Total variation] = [Common cause variations] + [Assignable cause variations] 


Assignable causes can be transient or persistent. Transient causes can be treated as 
a risk to the process, and actions should be taken in order to mitigate the risk 
(transient causes are rather infrequent and affect the process in an unexpected 
way). An example of transient cause is the inability to complete an activity due to 
power outage in an urban zone where power outage is rare. A persistent cause, on 
the other hand, is something that has not been treated by the process as an inherent 
part of the process and that becomes a frequent and highly expected problem. Some 
adjustments might be needed in quantitative predictive models or process 
capability to account for the effects of persistent assignable causes. The inability to 
complete the activity due to power outage in a remote and underdeveloped zone 
where power outages are routine is an example of persistent cause. 

Corrective actions can be performed to minimize or eliminate assignable causes of 
variation. When all assignable causes have been removed and prevented from 
recurring again, the equation above becomes [Total variation] = [Common cause 
variations], resulting in a stable and predictable process. Conclusion: Never stop 
control charting. 

6.13 Simulation of future state 

The statistical process-control methods listed in the previous section are powerful 
when used to monitor and control process performance. Simulation is the next step 
in terms of developing desired future states of process performance and identifying 
the gaps in current process that prevent transition to the desired future state. 

The definition of simulation is the enactment or representation of the behavior or 
characteristics of one system through the use of another system. In the case of 
business processes, simulation is enacting the behavior of a process, for instance, by 
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software that has the capability for simulation. In essence, a process is modeled in 
the software with all the associated parameters. 

An example of the cycle-time parameters for each activity: 

• In-queue time (before work begins) 

• Work delay time (from start of resource involvement until start of work) 

• Work time (from beginning of work to production of output) 

• Out-queue time (from production of output to release of output) 

Examples of the cost parameters are: 

• Total staffing costs allocated by headcount (labor) including the resources 
associated with each activity and the cost of each resource 

• Material consumed each time an activity is performed (direct costs) 

• Overhead allocated to activities requiring resources incurred over an interval 
of time, such as administrative costs allocated as a percent of labor (indirect 
costs) 

Other considerations with respect to the parameters are: 

• Number of times the process runs per interval time (X times/hour/day) 

• Decision points in process (example — 60/40 split between path A and path 

B) 

All of the process parameters are finally entered into the modeled process, and 
simulation is performed first on the current-state process. Once the simulation is 
completed, an output is generated by the software tool in a type of format easy to 
interpret. The output shows each activity with the time-metric dimensions 
summarized per activity along with the cost-metric dimensions summarized by 
activity. The output of the simulation allows identification of process performance 
problem areas that are supported by extensive data from the simulation. 

Once the current-state performance is completely analyzed, then the modeling of 
the desired future state process begins. Once the future state process is modeled, 
then the parameters are adjusted to achieve the desired process performance, and 
another simulation is run with a corresponding output generated for analysis and 
interpretation. 

The BPM practitioner can then adjust the parameters and continue running 
simulations until the process performs as desired. During the simulation analysis, 
the process model may change with the parameters until the final model and 
parameters are determined. This is all done in the modeling software before the 
BPM practitioner embarks on the actual process improvement effort with a team. 
This can save a significant amount of time, cost, and effort because all work is 
simulated in a software environment before it is implemented in the organization. 

Simulation using software tools provides an experimental lab for improving 
processes before actual implementation. It is not a substitute for the actual field 
work, nor is it a perfect method for determining the future state process. However, 
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it is a powerful tool to help the BPM practitioner more quickly assess the needed 
corrections than manually testing the changes. The biggest benefit of simulation 
through software tools is that it will automatically calculate the benefits of the 
process improvement across the Time, Cost, Capacity, and Quality dimensions. 
Simulation builds a data-driven business case for justifying process improvement. 

See chapters 3 (section 3.11), 5 (section 5.9), and 6 (section 6.13) for information on 
simulation. 

6.14 Decision support for process owners and managers 

Decision support for process owners and managers is essential for continuously 
monitoring the actual process performance. Limited or inaccurate information 
about business processes can lead to poor decision making about where to invest in 
and how to improve organization performance. 

Many organizations use a dashboard to monitor process performance based on the 
Balanced Scorecard (BSC) framework. These dashboards are a form of decision 
support and have been referred to as Business Intelligence & Analytics. Business 
intelligence generally deals with addressing process performance management 
within an enterprise context. When business intelligence is instituted at an 
enterprise level, it mines information about specific cross-functional processes and 
the performance of those processes in real-time, displaying the information in a 
dashboard format. 

Organizations that build broad capabilities for enterprise-level business analytics 
and intelligence understand that the capability goes well beyond data and 
technology: it includes the capability to address the processes, skills, and cultures of 
their organizations. 2 

The notion of decision support actually begins with the planning of "when," "what" 
and "how" process performance will be monitored and controlled. For example, a 
maintenance-schedule plan for a machine could include valves cleanup every 3,000 
hours, a conveyor belt tune-up every 1,000 hours, replacement of filters every 5,000 
hours, and so on. A clear maintenance plan is well thought out for the machine by 
the manufacturer and put into an owner’s manual. The actual following of the 
maintenance schedule is left to the owner of the machine. 

Process performance management generally begins with a plan for what processes 
will be measured, how often the processes will be measured, how decisions about 
process performance will be addressed when encountered, etc. Decision support 
frameworks, like the ones based on a BSC, are useful in the planning for monitoring 
of business processes. They enable the process review for the process manager. 

Once a process performance plan is in place and the organization has identified the 
cross-functional processes that will be monitored, the business intelligence and 


2 "Competing on Analytics: The New Science of Winning,” by Thomas H. Davenport; Jeanne G. Harris 
(March 2007) 
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analytics software tools provide insights into the performance of the business 
processes. The right information from these tools saves a lot of time detecting 
process performance issues. 

6.15 Process performance management maturity framework 

Depending on the maturity of the process management in the organization, process 
performance management assumes a different depth and perspective. Capability 
maturity models define maturity in a scale from level 1 to 5, where 1 is the level of 
immaturity and 5 is the high maturity level. At level 1 nothing is expected from the 
organization, but "just do it, go and deliver what customer wants.” At level 2, some 
cost, time, capacity and quality measurements, metrics, and indicators are defined. 
As the organization becomes more mature, at level 3 the process uses end-to-end 
process performance measurements, metrics, and indicators, neglects departmental 
boundaries and derives requirements from internal and/or external customer. At 
level 4, the process performance measurements, metrics, and indicators as well as 
cross-process performance management are derived from the company's strategic 
goals. At high-maturity level 5, process performance management as well as cross- 
process performance management is derived from inter-enterprise's strategic goals. 

The Software Engineering Institute’s (SEI) Capability Maturity Model Integration 
(CMMI®) is a reference model that provides best practices for improving processes 
for better products (CMMI for Development [CMMI-DEV]) and for better services 
(CMMI for Services [CMMI-SVC]). CMMI includes two Process Areas to deal with 
Process Performance Management. They are (1) Measurement and Analysis (at 
maturity level 2) and (2) Organizational Process Performance (at maturity level 4). 

According to the CMMI, the purpose of the Measurement and Analysis (MA) Process 
Area is "to develop and sustain a measurement capability used to support 
management information needs" 3 . MA Specific Goals (SG) are rather elementary, 
since they represent the first step from immaturity toward high maturity. For the 
MA Process Area, CMMI suggests specific goals, including: SGI — Align Measurement 
and Analysis Activities and SG2 — Provide Measurement Results. CMMI also suggests 
the following Specific Practices (SP) to achieve those goals: 

SGI — Align Measurement and Analysis Activities 

SP 1.1 Establish Measurement Objectives 

SP 1.2 Specify Measures 

SP 1.3 Specify Data Collection and Storage Procedure 
SP 1.4 Specify Analysis Procedures 
SG2 — Provide Measurement Results 

SP 2.1 Obtain Measurement Data 


3 CMMI® for Services, Version 1.3, CMU/SEI-2010-TR-034, SEI, Carnegie Mellon, November 2010 
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SP 2.2 Analyze Measurement Data 
SP 2.3 Store Data and Results 
SP 2.4 Communicate Results 

The purpose of the Organizational Process Performance (OPP) Process Area is "to 
establish and maintain a quantitative understanding of the performance of the 
organization’s set of standard processes in support of achieving quality and process- 
performance objectives, and to provide process-performance data, baselines, and 
models.” OPP has only one SG to achieve, namely SGI — Establish Performance 
Baselines and Models. Nevertheless, the OPP goal is more complex than MA goals. It 
is located at the higher organizational maturity level 4. OPP demands that certain 
capabilities are already implemented, including MA practices from level 2. CMMI 
suggests the following Specific Practices to achieve the OPP goal: 

SGI — Establish Performance Baselines and Models 

SP 1.1 Establish Quality and Process Performance Objectives 

SP 1.2 Select Processes 

SP 1.3 Establish Process Performance Measures 

SP 1.4 Analyze Process Performance and Establish Process Performance 
Baselines 

SP 1.5 Establish Process Performance Models 

Along with Specific Goals for both MA and OPP, there are also Generic Goals (GG) to 
be achieved through Generic Practices (GP). As a result, to achieve MA and OPP 
Process Area goals, an organization must also implement the following generic 
practices: 

GG 2 — Institutionalize a Managed Process 

GP 2.1 Establish an Organizational Policy 
GP 2.2 Plan the Process 
GP 2.3 Provide Resources 
GP 2.4 Assign Responsibility 
GP 2.5 Train People 
GP 2.6 Control Work Products 
GP 2.7 Identify and Involve Relevant Stakeholders 
GP 2.8 Monitor and Control the Process 
GP 2.9 Objectively Evaluate Adherence 
GP 2.10 Review Status with Higher Level Management 
GG 3 — Institutionalize a Defined Process 
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GP 3.1 Establish a Defined Process 

GP 3.2 Collect Process Related Experiences 

Organizational Process Performance overlaps Measurement and Analysis but with a 
different focus. The goal of OPP is to understand the usefulness of the process 
performance measures in the organization. The goal of MA is to introduce the notion 
and need for basic process measurement and analytic practices; OPP extends the 
concept with advanced process performance management practices. 

Process performance measures are beneficial when the cost of managing them is 
reasonable. Therefore, not all processes are measured and managed for 
performance. Only selected, critical processes are measured and managed for 
performance. 

OPP introduces focus on "quality objectives," not only on "process performance 
objectives," by covering product/service quality along with process performance. 
That will require a review of the organization’s business objectives for quality as 
well. Models for process performance are also required by OPP in order to estimate 
a value of a process performance measure from the values of other process 
measures. System Dynamics and Reliability Growth are both process performance 
models. OPP relies heavily on statistical process control to achieve performance and 
quality goals. 

6.16 Considerations for success 

An important part of any process performance management is the organizational 
structure necessary to support it. Some considerations include 

• Competency matching: making sure that the people who will perform 
process performance management actually have the skill sets to achieve the 
desired outcomes 

• Roles and responsibilities: making sure that roles and responsibilities are 
clearly defined and communicated 

• Organizational structure: making sure that the organizational structure is 
well prepared to accommodate process performance management 

• Empowerment with accountability: making sure those who are empowered 
to transform processes are held accountable for the results of the 
transformation 

• Process performance results: making sure that not only objectives are tied to 
roles, but also results along with behavior-driving compensation and 
incentives 

• Problem Avoidance: making sure performance measures are used in the right 
way for the right reason and are designed to avoid what Michael Hammer 
describes as the "seven deadly sins of measurement" in his book Faster, 
cheaper and better (2010). In many cases, the behaviors that the sins 
generate are a reflection of the organization’s culture: 
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o Vanity: using measures solely for the purpose of making the 

organization, its people, and especially its managers look good. Since 
bonuses and rewards are usually tied to performance measures, 
executives tend to expect favorable metrics. A realistic picture of the 
organization’s performance may sound more like a threat than an 
input for corrective actions 

o Provincialism: Functional departments dictating performance metrics 
under only what its managers can control (departmental process 
performance superimposing cross-functional process performance) 
o Narcissism: measuring from an inside-out point of view, rather than 
from the customer’s perspective (outside-in) 
o Laziness: assuming that it is already known what is important to 
measure without giving it adequate thought or effort 
o Pettiness: measuring only a small component of what really matters 
o Inanity: implement metrics without giving any thought to the 

consequences of these metrics for human behavior and consequently 
for enterprise performance 

o Frivolity: Not taking measurement seriously, arguing about metrics, 
finding excuses for poor performance, and looking for ways to blame 
others. 

Process performance management that focuses on the business goals and fosters 
transparency can provide a healthy environment in which organizations prosper. 

6.17 Key Concepts 


PROCESS PERFORMANCE MANAGEMENT— Key Concepts 

• Performance measurement is a journey — it must change as the business 
changes 

• The ability to support process performance measurement and then evaluate the 
results is related to the level of a company’s process management maturity 

• Performance measurement starts with performance monitoring and the clear 
view of what should be monitored and why 

• Performance measurement must be driven by evaluation targets — standards, 
KPIs, cost limits, etc. 

• Any performance measurement "system" must be defined through a formal 
workshop approach that is managed by the managers who will be measured 
and use the information 

• All changes should be managed through this formal workshop approach 

• Any performance measurement "system" will evolve, or it will become out of 
sync with the business and have little value 

• Measurement is directly related to the quantification of data (or data set) in an 

acceptable standard and quality (accuracy, completeness, consistency and 
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PROCESS PERFORMANCE MANAGEMENT— Key Concepts 
timeliness). 

o Metric normally represents an extrapolation or mathematical calculation 
of measurements resulting in a derived value 
o Indicator is a simple representation of a measurement or metric 
referencing a stated goal 

• Measurement associated with the work or output of the process that is 
performed is based on four fundamental dimensions: Time, Cost, Capacity, 
Quality 

• There are twelve characteristics of Process Performance Indicators: Alignment, 
Accountability, Predictive, Actionable, Few in number, Easy to understand, 
Balanced and linked, Transformative, Standardized, Context-driven, Reinforced 
and Relevant 

• Value Stream Mapping, Activity-based costing, and Statistical Process Control 
are widely accepted, reliable measurement methods 

• When a process is stable, the variation in process performance is predictable, so 
that unexpected results are extremely rare. 

• [Total variation] = [Common cause variations] + [Assignable cause variations] 

• World-class quality = on target with minimum variability. 

• A process performance management framework based on worldwide best 
practices, such as CMMI, can help process managers structure their process 
performance management practice to consistently achieve high levels of 
maturity. 
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Foreword by Tony Benedict, VP Supply Chain, Abrazo Healthcare; 
President, ABPMP 

Companies in every industry are engaged in business transformation. Some efforts 
are based on the selection and implementation of new application systems and 
some are based on the use of new technology or changes in business and in our 
society. Of all these change drivers, probably the most significant is that our 
cultures are changing on a global level in response to mobility technology and social 
applications. These are the foundation for a sweeping change in the way we look at 
business, success, and customers. 

The impacts of these changes are just starting to be felt. But they are causing many 
progressive managers to ask a totally new set of questions about how the company 
can function internally and how it can interact with customers and partners in a 
rapidly changing global marketplace. 

Successful process transformation has proven to be both pervasive and invasive. It 
forces management to look holistically at operations and ask tough questions. It 
also requires managers to look at the answers to these questions from multiple 
perspectives: process, people, technology, finance, legal, customer and strategy. 

This multi-dimensional look requires an ability to mix perspectives and balance the 
components of a solution, to compromise and yet produce an operationally optimal 
solution. Not easy, but critical. 

It also requires creating transformation teams with mixed skills and the ability to 
work in an open, collaborative environment where people are encouraged to think 
outside the box and leverage their backgrounds, disciplines, and creativity. This 
represents a new approach for many companies that are supported by BPMS 
technology and the ability to simulate and iterate that it provides. 

Using these design and deployment support capabilities, companies can embed 
performance measurement formulas in the processes as rules or Java modules and 
then generate applications. These applications can be run in a simulation module 
and iterated until the KPIs for the action are met. Because iteration can happen 
quickly, the team can try ideas in solutions and see what happens in the models. 
When optimal, the solution and the applications that support it (both generated and 
built in traditional languages outside the BPMS) can be easily moved into 
production. As always, however, data use and graphical interfaces need to be 
considered and made part of the "live” simulation tests. 

Many of the legacy and other constraints of the past are being removed by advances 
in collaborative BPMS technology and its adoption in BPM-based approaches to 
transformation. So, old paradigms need to change and professional process 
transformation practitioners must also evolve their thinking, skills, methods and 
approaches. 

The approaches, techniques and thought leadership presented in this chapter 
represent the combined experiences of several practitioners who are in the front 
lines of the BPM revolution, working in a variety of industries and companies. 
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When properly applied, the information in this chapter has proven to be effective. 
But success also requires that care be taken to bring all affected managers into 
alignment with the transformation’s strategy, scope, constraints, finances, outcome 
objectives, and more. Without this alignment, the transformation is at risk, as 
success will be based on opinion. Similarly, it is important that care be taken to 
consider organization development, talent management, and change management. 
Ultimately, people will make any transformation succeed or fail. They will find ways 
to get around minor problems and they will make things work if they have bought 
into the solution. 

Today, business transformation, leveraging emerging technologies and BPM 
methods and techniques, is positioned to change the way business is conducted. As 
BPM practitioners, we are at the front of this revolution and we are positioned to 
make a significant difference in the viability of the companies we work for. 


262 


Copyright ABPMP International 



Chapter 7. Process Transformation 


Contents 

Foreword by Tony Benedict, VP Supply Chain, Abrazo Healthcare; President, 
ABPMP 261 

7.0 Introduction 265 

7.1 Transformation: Beyond Improvement 265 

7.1.1 Why transform? Why isn’t improvement enough? 267 

7.1.2 Transformation and Improvement 268 

7.1.3 Strategic use of change: not a short-term gain 269 

7.1.4 Approaching transformation: not for the faint of heart 271 

7.2 Executive Commitment 271 

7.2.1 In it for the long haul: this is not a short-term commitment 272 

7.2.2 What is needed from executive management? 272 

7.2.3 What is needed from business-unit management involved in the 

process? 273 

7.3 Change management: Getting the staff behind transformation 274 

7.3.1 What is Change Management? 274 

7.3.2 Why is Change Management important to the BPM Professional? 276 

7.3.3 Expectations 278 

7.3.4 Planning Change Management activities 279 

7.3.5 People 280 

7.3.6 Stakeholder Management 282 

7.3.7 Leadership Involvement in change management 285 

7.3.8 Vision 286 

7.3.9 Organization Design 287 

7.3.10 Organization Development 288 

7.3.11 Communication 289 

7.3.12 Alignment 290 

7.3.13 Support 293 

7.3.14 Performance Management 294 

7.3.15 Process Transformation and Change Management 295 

7.4 Getting Ready for Process Transformation 296 


263 


Copyright ABPMP International 


Chapter 7. Process Transformation 

7.4.1 Creating a change-ready operation 298 

7.4.2 Funding: Always a problem 300 

7.4.3 Understanding the goals of the transformation 300 

7.4.4 The resources: Different people with different skills 301 

7.5 Transforming the business: reaching optimization 301 

7.5.1 Creating a Win-Win outcome 305 

7.5.2 The status of Legacy technology: help or limit to transformation 305 

7.5.3 BPMS and transforming the company 306 

7.5.4 Redesigning the operation: Process level, business unit workflow level, 

leveraging technology 306 

7.5.5 Performance monitoring and feedback to solve problems 307 

7.5.6 Delivering flexibility and speed of change: Arguably more important 

than savings (strategic use of BPMS/BPM vs. tactical short-term benefit) 308 

7.6 Sustaining Optimization 309 

7.6.1 Commitment to continuous improvement 310 

7.6.2 Evolving the process 310 

7.6.3 Continuous improvement 311 

7.7 Key Concepts 311 


264 


Copyright ABPMP International 



Chapter 7. Process Transformation 


7.0 Introduction 

In this discussion, we will follow the ABPMP definition of process: 

Processes are a set of functions in a certain sequence that 
delivers value to a customer. They are started by clearly defined 
external events. 

They are formed from a combination of all the activities and 
support that are needed to produce and deliver an objective, 
outcome, product or service — regardless of where the activity 
is performed. These activities are usually a cross-functional, 
cross organization aggregation of activities that work together 
to create an end product or service. Activities are shown in the 
context of their relationship with one another to provide a 
picture of sequence and flow. 


Process transformation is thus much broader than organization and business unit 
improvement. It is a look at the end-to-end work of the process and the way that 
work will change. However, because processes are a combination of work from 
several business units, their work and workflows will be affected and may be 
significantly changed. It is thus appropriate for the managers from all business units 
involved in the work of a process to be engaged in any transformation of the 
process. 

While it is recommended that transformation be process-centric, it can also be 
applied to organization-related groups of activity, function-based groups of 
activities, and other groupings of work. So, while the discussion in this chapter will 
be process-centric, other transformation groupings of work will be mentioned at 
times. 

7.1 Transformation: Beyond Improvement 

Process transformation is the fundamental rethinking of a process. The goal is 
innovation and the creative application of new business approaches, techniques, 
technology, and more. In this business redesign, no idea is off the table. No option is 
initially rejected — unless by company policy, law, or financial reality. Improvement 
is thus not the goal, but the by-product of a radical change to the way the process is 
approached and performed. This level of change is by nature invasive and will be 
disruptive. 

It should be noted that because process transformation is cross-organizational, the 
scope will include all the business units that are part of the process. However, for 
those who look at process as being the work within a business unit, the discussion in 
this chapter will still be relevant: transformation can be applied at any level in a 
business as long as it is related to the radical rethinking of how the business area 
should work — including its markets and products. 
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In transformation, the objective is to find a better way to do the work of the process. 
That may mean new production equipment, new applications, new IT infrastructure, 
new approaches to business, and new staff and staff skills. Transformation, by its 
very nature, is hard to do and requires significant investigation into what is 
currently available (ideas, techniques, concepts, tools, etc.) and research into what 
support/techniques are predicted to be available in the future. It is also a departure 
from the company’s past approaches and thinking, and is often uncomfortable for 
managers and staff. However, the burden of transformation can be spread out and 
gradually implemented to control disruption, reflect financial reality, align to the 
ability of the organization to absorb change, realign labor contracts, and much more. 
These are limiting factors — there will always be factors limiting creativity and 
innovation. These limiting factors must be identified at the start of the 
transformation to avoid rework and wasted resource investment. 

Transformation should involve seeking ideas from both inside and outside the 
company. However, it must be understood that what works in one company may not 
work in another. This is true for ideas, resource levels, best practices, approaches, 
etc. All information gathered at the start of the transformation must thus be 
analyzed for "fit" in your company. A failure to do this analysis has caused a great 
deal of trouble in many companies as they try to emulate another company with 
lower cost or some characteristic that management thinks is better than what they 
have in their company. 

The reasons for this caution are varied, but include differing management cultures, 
different IT infrastructures and capabilities, different production environments, 
possibly different state-level or international regulations, etc. So we urge caution in 
determining the targets for the transformation. 

In addition, any company will have transformation investment and other 
restrictions that require a phasing of the new operation’s implementation. The "big 
bang” (all-at-once) approach works in some cases and not in others. So, the 
implementation approach must be known up front so the design can be broken into 
phases — each of which has a group of specific deliverables and benefits. This is often 
tied to the ability to invest in new technology, new production equipment, or the 
timing of outsourcing. 

Once this transformation framework is in place, the project can begin. 

Because many companies have only a basic understanding of process, it will be 
necessary to start a process transformation with the identification and definition of 
the process that will be transformed. This will start with the modeling of the process 
(high-level process flow model) and identification of the business units that will be 
involved in the transformation. If existing business models exist, they should first be 
reviewed to see if they are current. If not, they will need to be updated or redone. 
Next, the team will need to determine what data they will need as a foundation and 
see what is available from the current business models. Together, these models and 
data form the starting point for the transformation. 
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In this model review, the transformation team should identify the more visible, 
immediate improvements and projects in order to take advantage of them, should 
they be initiated. This will provide immediate but short-term benefit until the 
transformation is completed. 

7.1.1 Why transform? Why isn't improvement enough? 

For most companies, transformation represents a costly, risky, and very disruptive 
option. But depending on the age of the process, its ability to provide consistently 
high-quality results at a reasonable speed and cost, its production capability, its 
competitiveness with the competition, and the company’s long-term strategy, 
transformation may be the best option. 

The fact is that improvement, while good, can only take any company so far in 
becoming more cost effective and competitive. In addition, for most companies, 
operational improvement will not produce a nimble operation or the ability to 
change quickly with low risk and low cost. 

By definition, improvement makes whatever you have better. It does not rethink 
it — it improves it. So, if you are looking for ways to do the same things faster, for 
lower cost, or with improved quality, you are doing the same things. At some point, 
however, the industry will have evolved. Technology will have moved beyond your 
ability to simply improve what you have. Your competition will have better ways 
and the market will require new approaches. 

For many companies, the response to these evolutionary changes has been to cobble 
together a solution that allows them to continue to do business. The solution works, 
but not well and everyone knows it. But it was inexpensive and didn’t cause too 
much disruption because it leveraged what they were doing and added to it. This 
solution eventually will cause a dysfunctional operation, and, transformation will 
become inevitable. 

For these reasons, transformation should be regarded as a strategic move. It is a 
long-term commitment to the business and to its ability to compete in the global 
market. It is also a commitment to modernize, upgrade, and rethink how the 
business should work in the future. 

The goals of the transformation should be carefully considered to ensure that they 
take a longer-term view. We have found that longer-term views and their goals are 
very different from the goals of a short-term view. For example, modernization has 
little to do with staff reduction. But that has often been mixed in with 
transformation. We have seen that staff reduction and similar goals of near-term 
thinking often put the transformation project on the road to disaster. People will 
simply not cooperate if they think their job or their friend’s job is at risk. Where 
these short-term goals are hidden, people will figure them out and trust will be 
destroyed. 

Transformation goals should thus focus on the modernization of the operation, its 
ability to compete, and the customer. Most operations are old and covered with 
change bandages. The operation’s structures are generally weak and don’t function 
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well. "White space" manual work is everywhere and applications don’t support the 
operation well. Even where large ERP solutions have been used to "modernize" the 
business, the areas outside the direct interaction with the ERP modules are seldom 
redesigned, and the ERP transformation becomes an island of improved operation. 

That is simply fact and it is found in any operation that has not recently been 
transformed. Operations that were transformed a few years ago can also be falling 
into mediocre performance — all operations eventually evolve into mediocre 
performance unless constantly improved. If they have not had the advantage of true 
BPMS-supported BPM to allow them to change rapidly following continuous 
improvement goals, the improvements may have become weakened by constant 
low-level change and much of the benefit may have been lost. 

Modernization uses the knowledge of the current operation as a starting point and 
then defines the products or services that are produced by the operation. But it 
must also look to the future and provide the flexibility to support new products in 
new markets. It then leverages new technology, new manufacturing techniques and 
concepts, and new management philosophies with a clear understanding of what it 
will take to win in the market. The goals of the transformation should thus start with 
a marketplace vision and then look at what it will take to accomplish that vision. 
These goals supersede all immediate improvement goals. This is why 
transformation is strategic and not simply improvement-based. 

7.1.2 Transformation and Improvement 

As noted, transformation involves a much greater change than improvement. As 
such, improvement becomes part of transformation and is applied to every aspect of 
the transformation project. The test here is against all problems, limitations, 
benchmarks, KPIs, etc., of the current process. In any transformation, the primary 
goals of flexibility and continuous improvement will remain the focus. But in 
delivering these goals, the team will need to test any solution against the current 
performance and the future targets. 

For this reason, the transformation solution design must begin with a firm 
understanding of the current operation and its metrics. The redesign will then move 
to a definition of limitations — that is simply reality. Next come strategy and the 
vision of the future. At that point, the team will be ready to start over and look at 
what business capabilities are needed and what activity is needed to support them. 

While the debate over the need for BPMS technology in BPM is still going on, 
transformation-level change requires the organization and analysis of so much 
information on the business, its rules, its use of IT, its problems, its use of 
outsourcing, legal requirements and much more, that it simply becomes too great to 
control manually — even with support from word processors, spreadsheets etc. For 
this reason, it is recommended that a BPMS be used to support transformation. This 
will not only allow control over the information and models, it will also provide an 
automated environment for solution design, simulation, modification, and then 
operational evolution. In addition, without a BPMS-supported BPM operating 
environment, it is almost impossible to change the business fast enough to become 
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nimble. This inability to provide fast change would limit future flexibility and 
options. See chapter 10, BPM Technology. 

The BPMS environment will also allow the transformation process solution to be 
broken into business unit subprocesses and for the subprocesses to be designed for 
improvement against goals or current benchmarks/KPI/costs/quality. Because the 
activities that comprise the work in the business unit will flow within the business 
unit and then outside it to other business units in the process, the design of this 
workflow will be complex and again require the support of an automated BPMS 
tool — to save time, improve the solution, and allow continuous improvement. 

Although the improvement of activity in each business unit is important in any 
transformation, management of the movement of work through the process from 
business unit to business unit is critical to the efficiency of the process and the 
quality of the process’s product or service. This management is a key factor in the 
transformation redesign and may be new to the company. Implied in it is the 
cooperation of all business unit managers involved in the process and the need for a 
process manager. 

This process flow is thus comprised of individual business unit workflows and 
provides a type of framework for their lower-level detail. Most importantly, this 
flow shows how each of the business unit-level workflows fit together and what 
flows between them (when, what, why, where). It also provides the requirement for 
the output of any workflow and shows the information/quality/documents 
expected by the next business unit downstream in the process. This allows the 
process manager to anticipate the impact of any change in a business unit’s work 
and to make certain that changes do not actually cause improvement in one place 
and harm in another. 

7.1.3 Strategic use of change: not a short-term gain 

As noted, transformation is really a strategic-level activity. It is an action that must 
take a long-term view of the business and not simply focus on short-term or 
immediate improvement. As a foundation to this view, transformation must tie not 
only to organization, but also to both current and anticipated business capabilities 
as defined by Business Architects. 

According to the Business Architects Association, the role of the Business Architect 
is to align business capabilities and their evolution to strategy. They then define 
how the business needs to change and the timing of the changes (see Figure 54). 

This shows what the business needs to do to deliver strategic vision, and the way 
the capabilities will evolve over time to support the delivery of strategy. Because 
business capabilities relate to business function, they tie to process through 
subprocesses (which combine to form functions). 


269 


Copyright ABPMP International 


Chapter 7. Process Transformation 



Figure 54. Business Capability decomposition 

Business functions are thus made of multiple subprocesses and include parts from 
multiple processes. A process, therefore, will probably be involved in supporting 
several business functions. Because of this structure, decomposing business 
capabilities also provides a way to identify how subprocesses and therefore 
processes will need to change to support strategy. This linking of process 
transformation to business capability and strategy is often given too little attention 
in transformation-project planning and execution. This is reflected in the solution 
and its ability to support strategy, evolving as the strategy evolves. 

Process Architects now take these change requirements and analyze their impact on 
process to consider the changes on the work in the business units in terms of both 
performance and quality. 

This sets the foundation for the transformation. At this point the project manager 
will be able to identify high-level goals and how the business needs to change to 
meet them. He or she will not, however, know what changes will be made or the 
details. 

The scope of the transformation can be anticipated (processes and business units 
that will be involved) at this point, and removing the major weaknesses in the 
current operation can be aligned with benefit. This can be used to create a high-level 
vision or conceptual new design. 

The impact of the change on the company’s IT and to production or other equipment 
can now be estimated. This is what determines cost and disruption. Adding culture 
to the mix, we now have the ability to look at the company and its people’s ability to 
absorb change. This gives us a first draft of the limitation, requirements, timeline, 
and distribution of change and cost over the timeline. 

This is the basis for a roadmap that should tie outcomes to specific time points and 
identify how those outcomes will be measured. This will provide a clear tie to the 
impact of a strategy and the rolling benefit of the strategy over time. 
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7.1.4 Approaching transformation: not for the faint of heart 

Business transformation is bold, revolutionary, multi-year and expensive. It requires 
a long-term commitment to optimize the operation. Given the advantages of a 
BPMS-supported BPM operating environment (see chapter 10, BPM Technology), it 
should also be BPMS/BPM-based and move the operation into a state of rapid 
continuous improvement. This sets the operation on a path of continuous change as 
it sustains optimization. 

Transformation is without doubt much more intense, disruptive, and costly than 
improvement. Given the risk, cost, disruption, and fear, why go this far? Earlier in 
the chapter we talked about benefit, and while it is clearly there, benefit is not the 
only reason. As noted, at some point in the life of any business operation, 
transformation becomes necessary to deal with the built-up effect of piecemeal 
changes that have been made over time. When this point is reached, the operation is 
on its way to becoming a competitive anchor, which simply must become more 
efficient and effective. The business must change fundamentally to remain 
competitive and it must provide the platform for rapid change. 

To do this, transformation must be invasive and it must be totally supported at all 
levels in the company. Because it is both costly and disruptive, it is risky and scary. If 
done right, it goes far beyond improvement to a fundamental rethinking of what 
business the operation should support, how the support should change, and how the 
business should really operate (local, national, international). This fundamental 
rethinking ties to vision and business-capability changes to deliver the capability 
(must be able to change fast) and operational changes that are needed. 

Unlike improvement, which can happen in a focused way to solve a problem, a 
broader-based use of BPM to support transformation requires the guidance of a 
person who is experienced in business transformation-level projects. This skill is 
not industry-specific and not-company specific. It is, rather, transformation 
experience-specific. This is important in delivering flexibility and improving control 
over the business operation without serious missteps. 

Because of transformation’s scope, impact and risk, management should look at 
creating a target design and then breaking it into parts (components) that can be 
implemented following a plan that recognizes the constraints of the company. (See 
section 7.3.1). This creates an approach that can be controlled and deliver benefit on 
a continuing basis. In this way, the risk is minimized, the design can change as needs 
change, cost is spread and recovered as new components are added, and people are 
much more easily trained and likely to accept the new operation. Disruption is also 
minimized and the operation’s culture can evolve slowly instead of having to absorb 
serious change in a short time. 

7.2 Executive Commitment 

Because business transformation will change the fundamental way business is 
approached and performed, it requires a long-term commitment by the executive 
management team, a commitment of time, resources, funding, and public backing. It 
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must also include time from the executive managers to look at ideas and provide 
guidance on how the new operation design must work to support their strategy. 

In addition, there will be a great many political problems and conflicting priorities 
as the project is performed. The executive sponsor must have the authority to 
resolve these conflicts or have access to those who can. 

Transformation will also change the culture of the business or the part of the 
business that is transformed. This level of change must be backed by management at 
all levels — including the executive level, which will need to define the new culture 
and determine how to create it. 

If this involvement or other types of backing fail, the project will not be more than 
partially successful. 

7.2.1 In it for the long haul: this is not a short-term commitment 

To maintain executive interest and commitment, it will be necessary to take an 
approach that implements the new design in planned phases (components using sub 
projects) that build on one another to deliver the new operation with visible, 
tangible benefits and as little operational disruption as possible. In this approach 
the transformation would create the new design and then coordinate with IT for 
changes in the IT infrastructure or approaches to applications delivery, interfacing, 
or web applications use. This will allow the team to create a timeline that ties the 
reconstruction of the business to IT change and, if needed, to production-equipment 
change. From this timeline, the team can predetermine deliverables by estimated 
completion date and make certain they are produced on a frequent enough schedule 
to ensure rolling delivery of improvement and benefit. This approach is much more 
palatable to most executive managers because it is based on an increasing benefit. 

It also sets the stage for a longer-term transformation roadmap. In this case, the 
move to continuous improvement is an extension of the roadmap’s timeline, 
showing the implementation of the performance measurement capabilities 
(business strategic planning, anticipated marketplace change planning, Six Sigma 
quality measurement, performance measurement, IT infrastructure change, etc.) 
that will point to improvements that can — or need to — be made to maintain 
optimization. 

7.2.2 What is needed from executive management? 

The simple answer is active engagement, with vocal commitment and funding. The 
harder answer is the "will" to see the transformation through, giving it a high 
priority and removing obstacles to its success. If possible, this should set the stage 
for the transformation to continue, even if senior management changes. 

Part of this commitment is related to decision-making. The transformation team 
must expect quick decisions from the executive committee (CEO, COO, CFO, CIO, and 
VP HR). Indecision will kill the effort by bogging it down. This is true at all levels. But 
making decisions that have a profound impact on the business is difficult for many 
managers — especially those in an environment where the key focus is finding 
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someone to blame instead of iterating problem decisions and improving them. For 
many companies, this represents a move to a learning organization that tries a 
solution and then, if it doesn’t work, iterating it and correcting any problems. This is 
a significant cultural change for many businesses. It should, however, be a goal of 
the transformation. 

The transformation team should expect the executive committee to remove 
obstacles to their success. As issues are raised, it is important for continuity and 
momentum that they be addressed and resolved in a timely manner. The tough 
issues will be brought to the project’s executive sponsor and, if necessary, to the 
executive committee. The expectation is that the obstacle will be removed — the 
issue resolved. When this doesn’t happen, the estimates and project schedule will 
become inaccurate and eventually meaningless. 

In any fundamental rethinking of a business operation, many may react with fear 
and protection of the status quo. Dealing with this is difficult, but it is also the main 
role of the executive sponsor and the executive committee. When faced with major 
changes, it is a good idea to add a change management team who can deal with the 
day-to-day and provide proper guidance to the executive team in terms of critical 
issues to address and how to move the organization along. See section 7.3. 

As part of the fundamental rethinking of the business, it is important for the 
executive committee to consider many things that they seldom address — including 
the organization structure, compensation system, management evaluation system 
and other factors that will influence the way managers and staff look at the 
transformation. 

7.2.3 What is needed from business-unit management involved in the 
process? 

Buy-in is needed from mid-level and lower-level managers, but it is often difficult to 
obtain. Experience has shown that many managers and staff will look at 
transformation as a declaration that they have failed and their operations are so bad 
that nothing short of fundamental rethinking can save them. This is partially 
because everything must be questioned and justified — including what the managers 
and their staff are doing, why they are doing it, and how they are doing it. This fear 
is cultural and it is common. But it can be overcome with senior management 
involvement and, over time, the proof in their responses. 

However, even with assurances and proof through examples that senior 
management is not looking at the need to transform as a failure on anyone’s part, 
some mid-level managers will still resist. Some, in fact, may feign interest and work 
behind the scenes to kill the project (unfortunately, this is fairly common). This is 
where the executive project sponsor comes in. Any form of passive-aggressive 
behavior or sabotage cannot be tolerated and must be stopped. 

In most cases these fear-based barriers can be broken by including mid-level and 
line managers as active participants on the project team — at least as much as they 
are willing to be involved. The transformation team will be mandated to do the 
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redesign, and the question is will they do it "with" the managers or "to" them. The 
answer is up to the managers. 

Persistence and patience also play a part in converting obstinacy and negativity. 
Constant good-natured questioning for interpretation and design consideration 
often brings recalcitrant participants around. The goal is for the company to win, the 
manager to win, and the people to win. Only when all of them win in the new design 
will the design be successful. 

7.3 Change management: Getting the staff behind transformation 
7.3.1 What is Change Management? 

Change Management is a term widely used and at times confusing to BPM and 
almost every other type of team because it could relate to strategy, technology, or 
organization\people. To help sort this out, below are the 3 most widely accepted 
forms of change management: 

Strategic Change Management: This type of change management addresses the 
process by which a company can find new opportunities and new ways to define 
itself to generate more profit. It focuses on analysis of the current performance and 
environment and usually leads to radical change for a company, such as abandoning 
a complete line of product, creating new product, or entering new markets. 

IT Change Management: This is the most popular and known form of change 
management. It describes the process by which IT professionals manage the change 
to IT applications and infrastructure to ensure minimum disruption of business 
operations and impact on users. The Capability Maturity Model and ITIL are 
excellent sources of information for those interested in learning more about this 
form of change management. 

Organizational Change Management: This type of change management is needed 
to ensure that the two previous types are rolled out properly in an organization. In 
this context, it is used to support large and smaller change efforts as well as 
incremental process improvement. This kind of Change Management is an iterative 
process that uses a set of tools to help an organization and its people transition from 
a current state to a sustainable desired state. It defines the need for change, aligns 
the organization, provides for the necessary skills & knowledge, focuses on the right 
objectives, prepares the organization for change and motivates employees to 
achieve sustainable results. 

Because BPM transformation is invasive and pervasive in any business operation 
being changed, the use of Change Management to truly transform a business or 
speed up adoption to maximize business benefits on a project initiative becomes 
critical. People ultimately make any transformation or improvement work or fail by 
their buy-in to the future state and adjustment of their behaviors in support of the 
new operational model and processes. Addressing the people-side of change by 
properly applying Organizational Change Management techniques is thus essential 
to successful transformation. In BPMS-based BPM projects, the involvement of 
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people from different groups forms an open collaboration that is highly 
recommended. "Hands on" involvement is also encouraged during at least the 
design and simulation of the new processes. This provides a chance for everyone to 
look at the way their jobs will change and to comment on the way they could best do 
their work — the workflow, the organization of the screens, the screen layouts, the 
data, the edits, etc. This is a level of interaction that is seldom found with traditional 
approaches to either applications-development or application change. This level of 
involvement is also fairly rare in business redesign, which often happens with 
significant management input, but limited staff input. 

This ability to involve those who will actually do the work is a strength of the BPMS- 
based BPM approach, but it is also a risk. Management and the design team must be 
serious about involving people. If they are not, they will not pay attention to 
comments and they will cause more harm than good, as people will lose trust if the 
issues they are raising or their contribution is not addressed in some way. 

Throughout the CBOK, the authors have made reference to BPM maturity and 
maturity models. Where your company stands in its BPM adoption and evolution is 
something you will assess, but the majority of companies that the authors are 
familiar with are currently at the start of their journey. At this level of maturity, the 
focus is on problem resolution and improvement projects. These tend to be fairly 
small. But they are critical in developing an understanding of the capabilities of 
BPM-based change and BPMS-supported BPM operations. This level of involvement 
is also the place for Organizational Change Management in a company to be aligned 
to the methods, techniques and activities in BPM and BPMS-supported projects. 
Moving further along the journey through BPM and BPMS use, the projects will 
become larger and more complex. Here transformation (not simply improving the 
operation) starts to become a focus. The assumption now moves from "the business 
operation is good enough and we only need to improve it by tweaking the work" to 
"a recognition that the business operation needs to be rethought and redesigned.” 

At this point the BPM Professional should look into their use of Strategic Change 
Management techniques to make sure that the objectives of the transformation are 
being well communicated. Once a new strategy is defined, the BPM Professional can 
ensure that the 'to-be' process design supports the new direction properly and the 
Organizational Change Management techniques needed to facilitate the new process 
definition, implementation, and adoption are defined, communicated, and in place. 

To implement proper Change Management, it is essential that the project leader 
determine how the different forms of Change Management will be relevant in their 
BPM project — especially if the company is in the early stage moving toward BPM 
Organizational Change Management. At some point, the transformation will move 
from the process level and begin to be driven by business strategy. As this happens a 
shift from Organizational Change Management to Strategic Change Management 
also needs to happen to ensure the right strategy is picked in the first place. 

IT-related Change Management can be needed at all levels of business change. IT can 
certainly be affected by strategy and it will almost always be affected by both broad- 
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based and focused tactical projects. It thus needs to be considered in all types of 
business change work, whenever technology changes are needed. 

While all these types of Change Management should be considered in 
transformation, we will focus this section on Organizational Change Management 
because it provides the tactics, tools, and practices needed to successfully execute 
any BPM-based change or transformation. Bridges provide great resources around 
Strategic Change Management (Leading Transformation) and CMM and ITIL have 
extended resources for IT Change Management, for those interested. 

7.3.2 Why is Change Management important to the BPM Professional? 

BPM is the harbinger of change. Change is a significant part of BPM and a serious 
subject to anyone who hopes to limit acceptance-risk in a project. BPM affects 
people’s professional lives by directly changing what they do and how they do it. 
BPM solutions are almost always based on the introduction of new practices, new 
rules, new tools, and new roles and responsibilities. 

But BPM and BPMS-supported BPM are still in their infancy and are not well 
understood in most organizations. People frequently have no idea of what to expect 
or how the BPM project will be performed. In addition, BPM is often associated with 
cost cutting, downsizing, and reorganization of work — all of which are scary to the 
staff. So, BPM projects often need to start with "damage control" to position the 
project in a positive manner This can be a great challenge for some organizations 
and requires considerable skill in managing change and leading people in a high- 
stress situation. 

Because new BPMS-supported BPM practices might be very different from the 
traditional ones, resistance may occur — especially if the project was performed with 
minimal stakeholder involvement (following a traditional approach of including one 
or two "experts" on the project). Without a solid foundation of Change Management 
support, the concept of the new business operation and the way the operation will 
work might be resisted and the completed solution rejected by the organization. 

Change Management in BPM can thus be used either to gain adoption of BPM as a 
new discipline in the organization, or to successfully implement a new process 
design resulting from a process improvement initiative or radical transformation. 
Working together, Change Management and BPMS-supported BPM bring the 
following benefits: 

• Low impact iterative change for improvement efforts. BPM is designed to 
iterate and will allow a team to evolve a solution until it works in the way 
management and staff think best. 

• Improved predictability on large transformation projects. BPM allows 
management a very different view of the operation and its processes; Change 
Management helps anticipate and mitigate acceptance issues. 

• Reduced productivity-loss through rapid redesign, construction and 
deployment of the solution. Using a BPMS, teams have reuse of models and 
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information along with a comprehensive picture of the operation and the 
generation of applications. 

• Reduced operations risk through simulation; improved testing. 

• Quicker adoption and reaching expected level of performance sooner. BPM, 
by providing a platform for ongoing involvement of the team members, 
makes adoption and learning faster. 

Not only does change management help engage staff, thus promoting acceptance 
and success of both transformation and improvement, it also helps drive the 
sustainability of improvements. This is a key point! Any change that is not 
constantly reviewed and updated will evolve to a mediocre state through constant 
rule interpretation and manual work-arounds as the business operation needs 
change. 

Sustainability using simulation and iteration is among the true benefits of BPM — 
especially a BPMS-supported BPM operation. Change Management assists in setting 
the stage for sustained operational change by 

• Building a culture of continuous improvement, challenging all levels in the 
organization to find new ways to improve the workflow and tasks. 

• Creating a training program that promotes taking a view of the entire system 
(policy, process, subprocess, organization, workflow, task, work step, etc.) of 
the business operation that the managers and team were involved in 
transforming. 

• Creating a culture of change based on a learning environment, where people 
evaluate what they are doing, what they have tried, what works and what 
doesn’t, learn emerging business techniques and then apply them to improve 
the workflow. 

• Defining the impact of the change and the actions required to successfully 
manage the risks and issues resulting from the change. 

• Communicating the change and determining appropriate means to develop 
ownership and build stakeholders’ buy-in. 

• Developing skills and providing coaching to support users and managers as 
they adapt to the new working environment and become change agents. 

• Anticipating and identifying resistances and concerns, intervening in a timely 
manner to minimize related risks and barriers. 

• Providing support and assistance to ensure alignment of culture, 
organizational structure, people, policy, processes, and systems. 

• Monitoring key metrics to implement actions for continual improvements. 

In this day and age when change is constant, people have often been negatively 
tagged as resistant to change. Actually, people are capable of amazing change. The 
key is the way change is presented. People can welcome change if it is introduced in 
ways that will be compelling to them individually and fit within their contextual 
frame of reference — which is often defined by current culture, immediate 
supervisor influence, and organizational policy and procedures. 
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Capturing the heart of an individual will not, however, be sufficient to guarantee a 
successful transition. To win acceptance, it is important to provide a well-aligned 
environment where the policy, process, procedure, tool, people, and incentive 
system all work together as a well-coordinated whole. In addition, an understanding 
of how people respond to change allows for better planning and the prevention of 
resistance. In general, some people have a higher tolerance to the disruption and 
uncertainty of change than others, but all of us have some capacity. Our capacity is 
mostly based on our working memory and existing mental maps, according to 
neuroscientists. Any new information coming our way is treated as known or 
unknown. The 'known' feels comfortable and is processed as it arrives. The 
unknown is pushed to our working memory, to be processed when enough attention 
is available. 

If people are asked to process too much unknown information without time for 
them to think it through, most will tend to slow things down and almost 
automatically go into resistance mode — even though they may later, after enough 
time to think about the information, accept the proposed information and the 
resulting solution or implication. For this reason, it is important to build in time for 
most of the people involved in a project to gain an understanding of the information 
being collected and to become comfortable with its implications, its quality, and its 
weaknesses. 

7.3.3 Expectations 

Because of the level of change that accompanies transformation, people must be 
prepared and their expectations must be managed. The best strategy is therefore to 
engage people early, communicate often, and in small increments. This is a type of 
internal sales plan for reaching and energizing the staff. 

BPM allows management to take a gradual approach to change and its acceptance as 
people are introduced to new ideas through involvement in finding solutions. The 
pace can be controlled to allow the project team and the business managers and 
staff to be introduced to ideas in an informal setting of team meetings, workshops, 
design sessions, and "hallway" discussions. This approach allows time for people to 
become used to concepts and information before they need to formally deal with 
them. The problem that must be closely controlled in this approach is the ever 
present "rumor mill." However, if rumor is controlled, this open and informal, 
gradual introduction helps remove the fear of job loss, status change, being 
transferred from friends, etc. 

In a well-planned and managed BPM change program, the business managers and 
staff who will be affected (within the project scope) will be engaged in the project 
and its change management activities at a very early stage in the project’s life cycle. 
This ensures that the participants gain an understanding of the significance of the 
change and are involved in planning proper communication, training, and other 
change activities in ways that are culturally acceptable. Through this involvement, 
the participants can gradually become involved and understand the project and its 
goals. The sense of acceptance and comfort this provides can be used as the means 
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to drive out fear and resistance. This gives participants an opportunity to embrace 
the change so they can contribute to the project team and the solution. 

7.3.4 Planning Change Management activities 
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Figure 55. Planning Change Management activities 


Identifying the right Change Management activities in support of your 
transformation or project improvement initiative involves consideration of options 
in a variety of separate but related business areas. These are shown in Figure 55. 
The core shows the involvement of people and sponsors. This represents both the 
project and business operation managers/staff participants. The component 
modules in the outer circle divide the areas that should be considered in a Change 
Management program into separate groups of issues and options for your initiative. 
In transformation-level change, this starts with the definition of clear vision for the 
change that should be aligned with the corporate vision and strategy and moves to 
include Organizational Design, Organization Development, Communication, 
Alignment, Support, Performance Management, and Process Transformation. The 
order of these components in the diagram below does not indicate any special 
relationship or sequence that the project team should consider when creating the 
BPMS-supported BPMS transformation project’s Change Management plan. It 
should be noted that considerations such as training are embedded at the next level 
of detail. 


Figure 55 is related to change management and not to a BPM or Process maturity 
model or a BPMS/BPM methodology. The diagram represents the activities that 
should be considered to support transformation and smaller incremental-level 
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change. The customization of the activities to fit the company culture and the project 
will be important in approaching the type and significance of the change that a BPM 
Transformation or Improvement initiative will bring. 

7.3.5 People 

Concern for the way people will deal with the level of change in a transformation 
should be a key area of focus in creating a change management plan. Companies are 
complex social organizations that are responsible for operating the manual and 
automated systems that create products and/or services. Without the effort, 
contribution, and dedication of its workforce a company cannot survive. However, 
highly repetitive work must be focused and controlled to ensure quality and 
efficiency. This mix creates an operation that is cohesive and effective in delivering 
value to the company (through profit) and to the customer (through good service 
and high-quality products). But the status quo has usually been built up over time, 
and changing it represents an unknown that must be well facilitated. The simple fact 
is that in today’s economy, people have often become overworked because of 
downsizing and acquisition-related lay-offs. 

This has caused many companies to lose touch with the staff and many managers to 
lose the trust of their staff members. Transformation based on the involvement of 
the staff and a sound Change Management plan can begin to address these issues 
and start to rebuild bridges that have been burned — unless the real goal is staff 
reduction. 

People knowledge, skills, and creativity are of very high value to an organization. 
Creating knowledge costs money and takes time — sometimes years. Many 
companies have found, to their detriment, that failing to consider this value in any 
transformation and acting accordingly can have a serious negative impact on the 
operation. Knowledge of history, an understanding of rules, familiarity with 
applications, and the know-how to deal with constantly changing problems departs 
along with the people who have these assets. The question is "what is this 
knowledge worth?" 

In assessing risk associated with a planned change, it is essential for the 
transformation project manager to understand the types of knowledge that the 
people who will be affected may have, which cannot be found in other places in the 
company — such as policy manuals, procedure manuals, etc. (which are usually out 
of date). In many cases, the only reliable source of rules, procedures, and much more 
is the people who do the work. If this is the case, certain goals related to staff 
reduction may need to be reconsidered. 

In addition, the transformation project manager should look at why people resist 
change and take steps to mitigate this resistance. This will provide a framework for 
planning how they may overcome this resistance — both during the transformation 
project and later in the continuing improvement phase of the BPM project life cycle. 

According to "The New Science of Change,” an article published in CIO Maqazine 
(Sept. 2006), 
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20% to 30% of people are change seekers 
20% to 30% of people see change as a threat 
50% to 70% of people are skeptics. 

Identifying which category the key transformation stakeholders belong in is tough 
because the true feelings of people are often hidden. However, categorizing the main 
project participants (change seekers, those who are threatened, or skeptics) is 
important in planning how to approach the change with them. Also, as the project 
team becomes more familiar with the key stakeholders and vice versa, opinions and 
people’s classification will change. This makes the strategy in dealing with the key 
stakeholders very fluid and iterative. 

The project team must keep in mind the key stakeholders’ motivations and 
concerns: what is in the change for them? Sometimes a hidden agenda might be at 
play; the possibility should be considered and steps should be taken to find the real 
motivators and fears. This is not always easy to do. Some people will say they 
support the change, yet do everything they can to stop it or make it fail. This can 
only really be identified by looking objectively at what people are doing — not just at 
what they are saying. The project managers must use discretion and understanding 
when addressing these real obstacles, but they must be addressed and removed. 

In looking at change resistance, it is important to consider the reasons for change 
and work with the people affected to address their concerns and fears, and to help 
them move along with the team, keeping an open, collaborative environment. The 
most frequent concerns observed on BPM projects include 

• Loss of power and control 

• Overload with current responsibilities 

• Lack of awareness of the need for change 

• Uncertainty about possessing required skills for future state 

• Fear, uncertainty and doubt 

• Distrust of the goals of change (lay-offs announced or fear of change) 

• Comfort with current state 

• Belief that it will require doing more with less, or for the same pay 

• Belief that it won’t do anything for them personally 

• Perception of it as extra work that will probably not be implemented 

• Fear that the new way will be more work and that they will fail. 


BPMS-supported BPM helps address some of these concerns by supporting visual 
mapping, simulation, and iteration. The approach suggested in this chapter is also 
part of reducing these concerns and the risk of resistance. Involving a great many of 
the staff for short periods and asking for their opinions is considered by some of the 
more traditional project managers to be unnecessary. We disagree. Experience has 
proven that external expertise ("we don’t need to talk to anyone because we are the 
experts”) or the involvement of one or two business-area experts is not enough to 
overcome these concerns. Only by involving many of the people can these concerns 
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be overcome. Involving the key stakeholders early and communicating often in 
small increments is a key success factor in any significant change initiative. 

During the project, communication with all staff and management levels will thus be 
important. In these interactions/discussions, attention should be paid to the tone 
and content of the message. The way engagement and change communications and 
discussions are worded will either help control fear, or cause it. If a change is 
significant for an individual, the individual will most likely follow some stages of the 
grieving cycle as described by Kenneth Blanchard in Who Moved my Cheese? The 
stages are denial, anger, bargaining, depression, and acceptance. 

It is important to recognize this cycle in any significant change. People will be 
comfortable with what they know, and how they have done things. The unknown is 
distrusted and feared. Any abrupt change (happens without the right setup or their 
involvement) causes personal insecurities and generates feelings of anxiety, as 
people feel that the change is needed because they are somehow at fault or that they 
are viewed as having failed. 

However, as noted above, following an approach that involves the key stakeholders 
can significantly impact this normal reaction to change that is forced upon the 
group. BPM-based transformation can be approached in only two ways — it can be 
used to do it to the staff (impose the change) or it can be used to do it with the staff. 

While there are shades of these two approaches, these are the only two options. 
However, when the staff is not actively involved in the change (the 'do it to the staff 
option), management builds distrust, resentment, and — often — active resistance. 
These projects take longer and deliver questionable results. On the other hand, 
experience has proven that designing and building the change with key stakeholders 
and significant staff involvement is less risky and better accepted. 

For this reason it is recommended that any change be approached with the full 
involvement of the staff and managers who will be affected. 

If this broad involvement approach is not acceptable in a given company culture, the 
project team will need to build remediation steps into the project plan. Resistance to 
change and the grieving cycle that can be associated with it are a normal part of 
change. The best way to address these factors is to anticipate, monitor, and manage 
them as specific tasks in the project plan. This will also require the involvement of 
human resource experts and it will be important to have the HR experts involved in 
these tasks. 

7.3.6 Stakeholder Management 

The project sponsor is the main stakeholder, but not the only one in a BPM 
transformation or improvement project. Clearly all business and IT managers who 
will be part of the projects are key stakeholders; so are finance (SOX, Dodd Frank) 
and legal, so are the employees (HR/union contracts) etc. But regardless of how 
stakeholder is defined, an extended group of affected business managers from 
related processes or, if the whole process is not in scope, managers from 
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downstream of the transformed business operation should also be considered in 
managing the change. 

This is critical because they will have an ability to claim that the changes disrupted 
their area and caused harm, so they must be involved. 

In addition, you might also want to consider people responsible for upstream 
process, if you would like to modify any of the input you are receiving for the 
process you are currently improving. If these business areas are not in the scope of 
the project, any changes to what they may deliver to the business activities in scope 
will need to be considered as scope changes, and may or may not be allowed. 

In any major effort or any effort that is considered critical, it is as important to know 
who disagrees with the project’s scope, approach, deliverables, etc., as it is to know 
who backs any part of a transformation effort. This evaluation of participants is 
difficult because of hidden agendas, but it is important that it be considered and 
then possibly evolved as more is learned by the project sponsor and manager. 

Using BPM, possible changes to the business operation will be identified after an 
initial fact-finding study — the analysis of the "As Is" model with supporting 
information. This is where those who may say they support the project, but really 
resist, will be identified. 

Although the resistance may be subtle (missed meetings, slow decisions, frequent 
decision changes, etc.) it can be found if the project manager looks for patterns of 
activity. As the new design is being built and simulated, the project team will have 
another opportunity to determine real support through action. Disagreement is not 
in itself an indication of resistance — unless nothing proves to be acceptable. 
Disagreement, when constructive, is actually a sign of participation and 
commitment to the result of the project. 

However, for those who truly act as roadblocks to success, mitigation steps must be 
designed with the project sponsor and, if necessary, discussed with executive 
management. If this cannot be turned around, the project may need to be adjusted 
and a new scope or deliverable defined. In this way, even if there are some who will 
not really back the project (with time, priority, access to staff or data, signoff, etc.), 
the project will continue. However, executive management must be aware of the 
situation and expectations set to reflect political and cultural reality. 

In addition to political- and culture-based resistance, we have found that once the 
possible solutions are discussed, operational success-related opposition can also 
build due to valid issues with other aspects of the organization. Frequent reasons 
for this success-related opposition are: 

• Proposed process does not align with current performance evaluation 
and reward systems 

• Proposed process is not supported by the current staff level and skills 

• Proposed process does not align with changing priorities. 

Once found, these reasons for resistance must be addressed as quickly as possible. 
Any resolution of the underlying causes of resistance must then be taken into 
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account in the possible process redesign (solution). A focus on key stakeholders and 
their concerns throughout this solution validation will help to ensure a process 
design suited to both its environment and the real needs of the stakeholders and 
their managers. 

As noted, stakeholders may be any person or group who could impact the project or 
be impacted by the project. The list of stakeholders for a transformation project can 
thus be long — the bigger the transformation, the bigger the stakeholders list. 
Luckily, not all the players in an organization have the same level of influence 
related to a specific change in a transformation. To make sure you make the most of 
the project-team’s time, the BPM transformation project manager needs to focus on 
involving those 'key' stakeholders that have the highest potential to make or break 
the change. Success is difficult if some of the transformation participants are not in 
agreement with the approach, the plan, the task, the way performance is measured, 
etc., so it is important to identify 'key' stakeholders and involve them, spending time 
to address any concerns, negotiate issues and address all disagreements. 

These stakeholders must become the project’s promoters to the key business 
managers (process owners or department managers). They must vocally support 
the project and the new design. This is critical. If any key business managers turn 
against the project, it will fail. 

As noted above, the project manager will need to identify, by key stakeholder, what 
is important (to them) and find a way to deliver that to them as the new design is 
built. But that is only a start in controlling change. Experience has shown that 
change must be sold at the personal level to be accepted. Managers will need to 
become comfortable with the idea that risk is being managed, creative solutions are 
being found, and that the operation’s performance measurement approach will be 
aligned to the new operation. This comfort is the foundation for acceptance, a trust 
that the solutions will not cause them harm. 

Also, the project team will need to consider the fact that every organization can 
absorb different amounts of change. There will be limits related to culture, trust, 
workload, etc. For this reason, each operation’s ability to absorb change must be 
assessed and the design and implementation plan must be adjusted to deliver the 
change in phases or steps that align to the rate and amount of change that can be 
integrated into the group. 

The approach to managing the project’s change requirement will be iterative and 
will change as the project is performed, based on continued interaction and the 
project manager’s assessment. By analyzing the result of the assessment, the project 
manager can prioritize the key stakeholders and develop a change plan that will 
take them to the desired level of acceptance. In this analysis of change acceptance, 
special attention must be devoted to influential stakeholders that have low level of 
acceptance. These people could have considerable negative influence on acceptance 
of the change in the organization, and specialized, flexible mitigation plans will need 
to be created and then modified as needed during the project life cycle to gain and 
keep their backing. 
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7.3.7 Leadership Involvement in change management 

BPMS-supported BPM is still new, and when used to support business 
transformation it requires at least training in the basics of BPM, an overview of 
BPMS and BPM methodologies, and basic training in the use of the BPMS. In 
addition, change management will take on a different emphasis through enhanced 
business-staff involvement in the project and in moving to continuous 
improvement. This change in transformation-project approach will require a 
commitment to training, and obtaining experienced transformation experts to act as 
mentors. Developing the leadership of an organization to better manage this BPM- 
based change will make a major difference in the speed at which an organization 
adapts to both transformation and continuous improvement change. This 
commitment to developing the needed skills is also a test of management’s 
commitment to the transformation. 

These and other collaboration-related BPM and BPMS techniques and tasks will 
require a rethinking of the company’s approach to change management. 
Transformation fear must be addressed and mitigated. If this level of change 
management is not addressed in your current change-management standards and 
techniques, it will be necessary to work with HR and IT to make certain the proper 
steps are taken, given the company’s culture. 

As with all types of projects, any project that may change culture must be closely 
monitored by company leadership. Executive, mid-level, and line managers must all 
agree with the way the culture will change and what new culture will be built. 
Without this backing and active involvement, the culture will not change and 
attempts to do so will cause serious staff problems. 

Leadership must thus be involved in all aspects of defining the new culture and in 
controlling the changes that will produce it. They must also monitor the evolution of 
the culture and the business operation to make certain that the staff’s concepts and 
attitudes are changing and that the new ways are being adopted. From this 
monitoring, they will be able to apply the right pressure at the right times to prove 
their backing and thus promote the evolution. 

Finally, with all the downsizing and rightsizing that has occurred, many 
organizations are operating under-staffed and have their mid-level managers 
focused on daily activities and routine instead of leading and inspiring their team. In 
these cases, we have seen a higher level of change success when time is taken to 
train or re-engage the mid-level management’s leadership skills. Essential skills for 
the mid-manager in leading transformation comprise communication, engagement, 
collaboration, and empowerment. Experience has shown that BPM transformations 
have a greater chance of success when managers pay attention to their people and 
their concerns, promote collaboration amongst leadership levels, and focus on staff 
growth and building improved capabilities. These are critical elements of any 
successful transformation; failing to give them the attention they need increases risk 
and builds staff distrust. 
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7.3.8 Vision 

Any transformation should be aligned with company vision, mission, and goals. 
Going further, management should also have a clear separate vision for the 
transformation project — what the new business operation will look like and how it 
will perform. This vision of the new business will include the use of a BPMS and 
BPM to deliver the transformed business and continuous improvement, clear 
metric-based performance goals, and definable operational characteristics. This 
vision will also include the organization structure needed to govern work and the 
capabilities of the staff. In some cases, this vision will also begin to move the 
business toward a process-view of the operation and the use of performance 
measurement and analysis to move to continuous improvement. On the IT side, this 
vision may also include SOA and other modern technology and concepts such as 
cloud computing. 

For most companies, a part of the business vision will be work reduction, quality 
improvement, improved flexibility, speed in changing, and improved management 
control. If possible, staff reduction should not be a key part of any vision to change 
the company. The reason is that although there is a short-term cost reduction, there 
is a longer-term cost increase, as knowledge, training, skills and competency are lost 
with staff reductions. Also lost are trust, commitment and loyalty as fear takes over 
and productivity is lost. This is a high price to pay for a short-term cost reduction. 
But that is a decision that will be made outside the transformation (in the business 
case) and will be a key guiding factor in the project. 

In performing any transformation, or in many cases improvement projects, the 
people who will be affected need to understand why the change is needed and why 
it is needed now. A good vision will compel them to support the change and act 
accordingly. However, if they cannot be assured that the change will not affect their 
jobs or pay, experience has proven that most will simply put one obstacle after the 
next in the way of the transformation. This can remove benefit and produce a poor 
solution. It can, and has, caused projects to fail. 

The project team, following sound change-management practices, will need to 
establish a sense of urgency in the business managers and the staff. It is also 
recommended that the project sponsor clearly set the stage for those affected to 
gain something, instead of lose something. The transformation vision should 
therefore be compelling and stimulate people to act quickly. We have found that 
engaging people by asking their opinions causes excitement and helps create this 
sense of urgency. But this must be based on a foundation of trust. To help build this 
foundation, it is important to position the transformation in a positive light at all 
times. If management positions the transformation in negative terms ("we must do 
this to cut staff and save money," or "we are doing this to prepare for a move to x"), 
the participants may find incentives to make the project fail — and they may well 
succeed. 

A last thing to consider while preparing a vision statement is to go beyond the 
immediate project objective(s). BPM team members are often very analytical people 
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by nature and are persuaded by numbers and rationale, while the rest of the staff in 
an organization may be moved by something more emotional and inspirational. We 
have found that transformation projects with an inspiring vision gain alignment and 
momentum much faster than those with a vision limited to economics. This is 
important in selling the change to managers and staff, and in avoiding skepticism 
about the change being "the latest management fad." 

7.3.9 Organization Design 

Too often organizations are defined before processes are defined — requiring 
management to make the processes work within the boundaries of the existing 
organization. This practice can lead to frequent and inefficient handoffs, quality 
issues, and disconnects in the work. To help avoid these problems, as new processes 
are defined in the transformation project, special attention should be given to the 
organization and the possibility of reorganizing to better enable the performance of 
a process. 

In those transformations that are designed to move the operation to a process- 
centric model, it will be necessary to consider either redesigning the old 
organization structure to adjust to the new process view, or creating a separate 
process-manager role that is external to the organization structure. Both of these 
approaches to process management have worked, and the right approach depends 
on the company's culture. This decision will obviously be made with input from HR, 
but it should also have active input from all managers who will be affected and, in 
unionized shops, union representatives. 

In transformation projects that retain the old organization structure, the basic setup 
of the business will remain the same. Minor changes may, however, be needed, and 
if acceptable will become part of the new business design. In transformations that 
are limited in this way, the project team will need to take steps to make certain that 
the work in the different organization units is recombined to recreate the processes. 
This will show any holes in the process that need to be fixed and identify all 
handoffs that may need to be controlled. 

New processes may also introduce new roles or impact the level of staff skill needed 
in certain roles. As new roles are defined, job descriptions and performance 
measures should be updated accordingly. Often the impact on people varies by their 
roles, but most will be impacted. Defining roles will help business managers sell 
role-changes to the staff, tailor training and communication, and align compensation 
by roles. 

The key is that the organization can now be reviewed and redesigned as needed to 
reflect the work that will be done and how that work will fit into the larger process 
picture. This provides a chance to modernize the way the operation is structured 
and the way it is managed. 
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7.3.10 Organization Development 

In most cases, organizations have evolved in response to business needs. If they 
were designed, the design is often lost in the evolution. This evolution is often 
focused on structure, and the changes are seldom tied to training requirements; 
staff skills-improvement is often ad-hoc. Transformation projects offer a chance to 
change this situation and are the ideal time to help the business move to a "learning 
environment." This move to an environment where the staff and managers continue 
to learn and share experiences is a tough target, but it should be part of the 
transformation goals. 

For many companies, the move to a learning operation changes their culture. As 
such, it bears consideration along with the changes needed to move to continuous 
improvement and the many more changes to activities, approaches, and attitudes 
that make up a company’s or group’s culture. 

This shift to a learning organization relies on training — a primary organizational 
development tool and a critical part of any transformation. It is essential in change 
management and in delivering a successful new operation that supports the new 
operation model. Once the skill-needs and training objectives related to the 
transformed business design are well laid out, a skills assessment can be made and a 
training strategy developed. The training strategy should consider the population to 
be trained, their grouping by roles or other logical modes, the training approach 
(instructor-led class, coaching, self-paced learning, etc.), the training curriculum for 
each training activity, the list of training material needed, the identification of 
trainers, and a description of how the training activities’ performance will be 
evaluated. Stakeholders Matrix and Role Mapping are great for helping to identify 
and understand the population that will be impacted and design the right skill- 
development plan to support the transition. 

Once the process or business operation is transformed, work and process will flow 
differently, and many people will do their work differently. The approach that is 
taken in training will make a big difference in staff confidence and the success of the 
transformation. But just providing training is not enough. If it is provided too early 
in the solution development, it will be forgotten. If it is too general or too detailed, it 
will simply cause fear. So, training planning is critical and timing is important. 

If the staff has participated in the new design and in its evolution through iteration 
and simulation, they will be familiar with the way the new business will work. To 
remove the fear of mistakes, detailed just-in-time training on the business 
operation, each job, the new applications, the way the IT support will work, the way 
the BPMS environment works, and the way rules work, will be important. This 
training should end with a test. 

Weaknesses should be reviewed with each person individually to bring them to the 
level needed. During implementation, it is suggested that a mentor be available to 
help anyone who loses his or her place and needs help. 
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Given that staff acceptance is a goal, it is important to take all steps needed to create 
confidence in their ability to do their jobs in the new operations. This helps improve 
the results of the change and helps to avoid a long period of "trial and error" as 
people learn their new jobs. 

Promoting open questioning and requests for help in learning is often a cultural 
change; many are afraid to ask for help or admit that they don’t know something. 
This perception must be changed if the operation ever hopes to evolve into a true 
learning operation where people try things, learn, and then help the operation 
evolve. 

For most, moving to a "learning" operation model is in the future, but in 
transforming the process and the business units that perform its activities, the 
project team can set the foundations for this evolution. 

Before moving on to look at communication in the next section of this chapter, a 
special note is in order. The ability to deliver training is changing as new 
technologies allow new training options — starting with the use of social tools, 
mobile technology, and even network design. HR departments are usually well 
suited to support the project team in picking the right set of tools and techniques to 
balance the transformation team’s training strategy and plan, and should be 
consulted before any training approach is recommended. In projects where 
communications needs are addressed through flexible technology support, web- 
based training, complemented with online "help" support and coaching, is very 
successful. In projects where training is considered later in the project, a different 
approach will be needed and it will be necessary to provide more traditional 
"classroom" training opportunity. The trainer in these situations will play a critical 
change-agent role, as it might be the first time many people will hear about details 
of the change and discover its implications for them. To help avoid problems, we 
strongly recommend a well-balanced approach that includes leadership 
involvement, a formal training program, and open communication. 

7.3.11 Communication 

Communication planning should be considered during the project startup and 
updated at major points (milestones, phase gates, deliverable points, etc.) in the 
transformation project. Each update should be based on the project manager’s 
assessment (working with the business-unit managers) of which change 
management techniques are working and how change management issues may be 
resolved. This allows the plan, and the approach being used to control staff fear, to 
be adjusted as needed. 

The need for good, open communication cannot be overemphasized. It is historically 
one of the main fail-points in change management and it does not always work the 
way management thinks. Language can be imprecise and many clever people like to 
nuance their communication. When the result is misunderstanding, trust is lost. For 
this reason, communication should be direct and simple, using common language 
and terms. Nuance should be avoided. 
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A good communication approach is focused on keeping all stakeholders informed of 
project activities and progress. Maintaining consistent feedback is an important part 
of a solid communication approach and ensures an ongoing discussion with the 
project team and the leadership team. To encourage this two-way communication, 
the approach taken should give responsibility for this interaction to business-area 
line managers. This helps build a business-area network of project champions who 
will promote the benefits of the transformation in terms the staff can relate to: that 
is, what is in it for them. 

Note: While conventional wisdom focuses change benefit on the company, in today’s 
business world, people have largely lost loyalty to the company — especially in 
transformation projects where they wait to be laid off 

In this environment, success will rely on benefit to the company, to the line 
managers, and to the staff. If everyone wins in the transformation, the people will do 
their best to make certain it succeeds. Sound communications approaches use all 
means possible to reach managers and staff — e-mail, phone, web, handouts/posters, 
meetings, road shows, etc. As noted earlier in this section, the approach should be 
updated frequently in response to feedback and organizational reaction to change. 

In a BPM transformation project, the need for two-way communication becomes 
critical during the new design phase of the project. Here the design is meant to be 
iterative and the staff involved in each simulation to determine what is good about it 
and what needs to change. This involvement is somewhat unique to BPM. But it is a 
difference that can be used to assure success by driving out fear and making people 
buy into the solution before it is deployed. Then, following deployment as the 
business units in the process move into continuous improvement, this open 
communication with staff at all levels can be used to identify improvements and 
potentially redesign the business models and rules needed to make changes to the 
workflow, work management, and applications generated by the BPMS. 

7.3.12 Alignment 

A simple process change can have an impact on many other things in the 
organization (see Figure 56). Clearly, the alignment of these and similar factors 
affects an organization’s ability to get results — for better or worse. But in companies 
that are performing transformation projects, the alignment of these many factors 
may be a problem. 

Because of this, it will be necessary to consider how process, activity, problems, and 
the alignment of all the various business factors that define functions can be affected 
by a solution. A great many things that are done affect one another and must be 
considered together. Below is a graphical representation of major elements of an 
organization and how they relate to each other. 

This chart is more than a little complex: it represents the interconnections between 
some of the key parts of the business operation and shows that any change can have 
a considerable impact on other business areas and success factors. The diagram’s 
importance is in showing that the project team must consider a great many parts of 
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the business and manage not only how all will change, but also the ripple of any 
particular change. 



The ripple and tracking it are especially important in any project that addresses 
only part of a process. Here the team must consider the impact on process, people, 
and technology work downstream and the many components that define the 
business operation and how the overall process will be affected. 

Trying to attend to all of these factors or components is overwhelming. In our 
experience with BPM, the key areas to focus on when it comes time to aligning the 
different components of a change are the following: 

Key: Ex: Executives, S: Strategy, BI: Business Intelligence 
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Figure 57. Aligning people/operations (process) /technology 

One of our goals in a BPMS initiative is to make sure that the process we design (1) 
fits properly with the business strategy and other business and IT systems in place, 
(2) provides clear procedures for those who have to do the work, and (3) provides 
executives with sound reporting capabilities for progress and performance 
monitoring (see Figure 57). But this alignment is a constantly shifting target as 
organizations experience change on an ongoing basis. As such, it should be 
recognized that it impossible for us to reach and keep perfect alignment. However, 
the goal should be to bring the new business design as much into alignment as is 
possible to help glide the change through its introduction. 

Other factors in this complex interaction will rise to the surface as issues and 
concerns are discussed and can be addressed as needed. 

Another thing to consider is the alignment of the change management plan to the 
level of impact a project will have on the business operation. For smaller BPM 
improvement projects, the project’s impact on the change-management approach 
taken may not be significant. However, in transformation, the impact will, by 
definition, be significant: it will be invasive and pervasive. Transformation changes 
the fundamental approach to the business operation with new ideas, new 
approaches, new applications, and more. The new business design will need to make 
certain that the new work activities and support all align to deliver what is needed. 
The change management plan and approach used in this type of project must be 
designed recognizing the true issues and concerns that the transformation holds for 
managers and for staff. 

The approach to managing change on the staff must also be designed to align with 
the level of risk associated with transformation. It must bring the ideas of the 
affected managers and staff and all other factors into a type of cultural alignment 
with the goals and needs of the operation. As noted above, this requires a flexible 
approach that will adjust as the project changes the business and as people become 
more involved. 

Clearly, the faster all of these aspects of change can be brought into alignment, the 
faster the change will be assimilated by the business managers and staff. But the 
opposite is also true. The greater the misalignment, the higher the risk of failure and 
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the higher the probability that the solution’s validity will be challenged by those 
affected. 

7.3.13 Support 

Support for Change Management must start during transformation project planning. 
It is important to adequately address the human part of the change equation as early 
as possible in the project because people can make a moderate solution a success, 
and a good solution a failure. The difference is related to their involvement in the 
project and their acceptance of the solution. For this reason management at all 
levels should clearly support the need to address the cultural, HR, salary, evaluation, 
and overall performance measurement aspects of the project. 

Following traditional project management approaches, the project is often formally 
closed as soon as the deliverables are completed and accepted by the sponsor. In 
BPMS projects we carry this one step further and track the adoption of the change 
until desired performance is reached. We also try to have the right support structure 
in place to mentor the people who have been impacted and answer any questions on 
a variety of issues — on the new systems, the individual's new role and 
responsibilities, the new processes and any other area where questions may arise. 

Access to the available training and support should be clearly communicated and 
made easily available. However, it is the responsibility of mid-level and line 
managers to make certain that every person who will be affected has time to take 
this training, demonstrate their understanding of it when tested, and are ready to 
perform their activities in the new business operation. 

Executive Leadership should also be ready to answer questions such as, why are we 
doing this? Why now? How does it fit with the corporate direction, vision, and 
mission? And is our corporate strategy changing? The more transformational the 
project, the more the staff will be eager to hear from the executive. 

Mid-management should also be well prepared to answer the questions important 
to their direct reports. These include: Is my role changing? Are my responsibilities 
different? Will we have training? Who can help me if I am struggling? Will my bonus 
structure change? Will we be evaluated differently? 

In all changes, both managers and staff will want to hear from their immediate 
supervisors (often the mid-management layer) about how the change will affect 
them personally. 

Two other groups that might also need to be ready to support the implementation of 
changes in the new organization are the HR group (in case of significant change in 
roles, responsibilities, and performance evaluation structure) and IT (if new 
systems are put in place and help-desk staff need to answer questions related to the 
new systems). 

The identification of support needs and the people whose support will be needed 
should be considered as early in the project as possible and built into the change 
management approach and plan. This will help relieve anxiety amongst 
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management and staff and show that the transformation is important to the 
company and to individual people affected by it. 

7.3.14 Performance Management 

In certain corporate cultures, people have become afraid to be monitored and 
measured. If, in the past, measurement has been use to punish managers and staff, it 
will have created a climate of distrust, because it is human nature for people to hate 
anyone looking over their shoulder and evaluating them when motives are 
questionable. That must be changed if innovation and outside-the-box thinking is to 
be part of the transformed business process. This breaking of old barriers will take 
time as management builds trust. However, this is a change that will need to be 
driven from executive levels down and promoted frequently by executive 
management. 

The change from a fear of evaluation to an openness to try new ideas should be part 
of a move to a learning organization where ideas are sought and tried in simulation 
(something that is not possible without a BPMS or simulation system). Performance 
monitoring and measurement in this innovative environment takes on a different 
meaning and is not viewed as punitive. 

In the transformation project, performance goals should be clearly defined targets. 
The simulation modeling of the "As Is” business will provide a baseline of the 
current performance. Business managers and staff will be able to use the baseline to 
measure the delivery of the project’s goals as improvements against the current 
operation. Using iteration with the simulation, they will be able to help design 
optimal solutions and prove that the solution should deliver the goals. This allows 
the project team and the sponsor to learn from each iteration, and apply the new 
insight to the next iteration. In this way, the team continues to grow in knowledge 
and ability while the new solution evolves to a measurable level of improvement. 

This approach promotes acceptance of the final design because it gives the project 
team and all who are involved in the design and measurement, a say in how the 
goals will be made. Also, during the definition of the goals, the business managers 
will have had input into how performance will be measured and evaluated — the 
data and the formula. This involvement is part of a change management approach 
that is designed to make the move to performance monitoring, measurement, and 
evaluation more acceptable. And acceptance, as discussed elsewhere, is critical. 

Performance Management, when used appropriately, is a very powerful tool in 
helping people clearly understand performance targets, their role in delivering 
them, and in determining how the organization is progressing toward them. 
Implementing the performance program also provides a good opportunity to engage 
people in discussion of how well the change is coming along and what can be done if 
the performance is not as expected or desired. 

Finally, as mentioned earlier in the chapter, it is essential to make certain that the 
new performance measurement process and targets align with each individual’s 
performance evaluation goals. If the two do not align, the individual performance 
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evaluation targets will need to be used in any evaluation. People are motivated to 
meet their individual performance goals to obtain positive recognition from their 
supervisor and any financial gain associated with good performance. 

7.3.15 Process Transformation and Change Management 

As we have discussed, change management and the human side of the 
transformation equation are a critical part of business process transformation. The 
rest of the project deals with activity and technology, both of which are critical. 
People, however, will make the transformation succeed or fail, and omitting their 
active involvement can lead to serious problems. 

Change management helps the project team focus on the people who will use the 
solution. In transformation, unlike with improvement, as the business operation is 
changed, the people’s jobs will change. This includes the rules they work with, the 
way they do work and the way they are evaluated and paid. Transformation touches 
all of the business operation within scope. This is unsettling to many — especially to 
those who have been doing the work for some time and are comfortable in their 
success — but keeping them on the outside to save staff cost is a mistake; their 
knowledge is simply too valuable to ignore. Bringing them into the transformation 
will be the main driver of the solution’s concern for human engineering, and it is 
critical it be performed in the right way. As discussed, because of its scope and 
impact, the change management activity will need to be a formal part of the 
transformation’s plan and execution. 

The information in this section is a good overview of some of the things to consider 
when looking at change management — but it is not all of what must be considered 
and is not customized to your company. For this reason, it is important to work with 
change management experts in your company to determine the best way to 
approach cultural change and training. 

Change Management Summary 

A well-managed change should 

• Call out tangible benefits for the individual and the organization 

• Have a shared and compelling vision 

• Have visible and committed sponsors and leaders 

• Promote early, with frequent and active stakeholders’ participation 

• Build ownership and accountability; create transformation and BPM 
champions 

• Ensure effective communications are integrated with solid Project 
Management practices, especially around risks and issues 

• Offer appropriate support during and following the project 

• Continue after "go live" until adoption and performance have reached 
expected levels. 

Investing time in change management to focus on the people side of transformation 
increases the probability of success, speeds up adoption, and decreases productivity 
loss. It is also important in driving out fear and increasing trust and loyalty. This 
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creates a foundation for solution optimization and continuing improvement — both 
important to the company. 

7.4 Getting Ready for Process Transformation 

Business transformation must start with strategy and either its confirmation or 
change. It must also deal with the perspective on the direction the company will 
take and what taking that direction will mean: how the company will change and 
why. This is the strategic side of business transformation. Once the strategy is 
approved by executive management and/or the board of directors, the 
transformation moves from the conceptual to the physical: that is, real changes to 
the business operation. The team and the company will now know why this is being 
done and what is expected in terms of change, goals, and support for a new 
operating direction. 

To begin any operation transformation effort, the company must understand the 
way the business operation really works, and not just how people think it works. 
This is where the conceptual understanding and the physical reality meet. Every 
operation exists to perform work that supports some service or production strategy. 
But in the normal hierarchy of an organization, the understanding of the business 
operation and why it exists changes as one moves up or down the organization chart 
from the line manager. 

Most senior managers will have a sound understanding of how the operation is 
supposed to be working. At a conceptual level, the company usually does work that 
way. But then comes the translation of the conceptual into reality — the work that is 
done and how it is performed (including decisions and rules). This is where 
disconnects often happen. The fact is that few senior people need to understand 
how the business operations work at a mid-level of detail or lower. They do 
understand what each business unit does and what each produces. But 
transformation must also deal with the way work is performed. So, it is necessary to 
recognize what managers at each level can offer and how that knowledge can be 
leveraged at the appropriate time and place in the transformation. 

To take advantage of this, it is necessary to define what the team will be looking for 
from managers at each level in the company. Standard questionnaires that can be 
modified to the individual manager should be created to make certain the team 
looks for the right level of detail from each interview. 

Senior managers will play a critical role early in the project, when an understanding 
of strategy is critical. This level of management deals with strategic change and is 
responsible for looking at the business and making fundamental, broad-scope 
operating decisions and changes. This is business reengineering, and it is critical in a 
transformation effort. It ties strategy to change and to the business operation and 
defines how the fundamental rethinking of the operation supports the strategic 
goals of the company. 

Here the senior managers deal with business capacities and the business functions 
that make them up. Creativity and the application of new technology are important 
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here — possibly more important than at any other level in the transformation 
because they create the foundation for the change. Because strategy deals with 
concept (it has no direct execution or physical components), we can consider it a 
conceptual model. 

Following this fundamental rethinking of the operation, transformation activity will 
focus on the mid-level (department or business unit) manager for each business 
unit and then line managers, as the transformation effort moves to a lower-level 
operational view. 

These mid-level managers now have the responsibility for looking at how the 
reengineered business (high-level) conceptual design will affect them and how the 
physical models of their operations must change. Fundamental rethinking also 
happens at this level. In moving from the conceptual design level to the physical or 
execution design level, the managers have a choice of approaches. They can follow 
the traditional organization model or move to a process-based operating model. 

Part of the difference is (and the BPM bias says) that a process focus allows you to 
look at the entire end-to-end process and optimize it. Then look at how the business 
units that support it will change and how they will each optimize their operation. 
The advantage is a broad-based optimization instead of organizationally focused 
optimization that may fail to provide real improvement at the higher process level. 

In both approaches, the optimization eventually gets to the business unit level. The 
concern is that it is possible make improvements in a business unit that cause 
serious problems in downstream activities in other business units. In addition, an 
organization approach limits the type of performance monitoring and measurement 
that can be done. 

Line managers and their staff become critical participants at this lower level of 
detail, in the definition/analysis/redesign. Every activity, task, scenario and 
delivered subassembly, service, etc., must be reviewed and questioned. Each must 
be justified and those that remain must be viewed with a critical eye for 
fundamental operational change. All manual work must be questioned. All quality 
KPIs and standards must be considered, along with effectiveness and efficiency. 
Following a process approach, the mid-level managers must work in collaboration 
to make certain this design improves both the process and their work. In reaching 
consensus on the new design, it is possible that any manager may need to 
compromise and go along with a solution that, while not optimal for them, is optimal 
from a process perspective. 

Participating managers then need to focus on their business units as the project 
moves forward and the lower-level designs must be built, including the information 
needed for application generation or the building of application system specs. 

This allows the business unit workflow and activities to be combined to form 
processes and then aligned to business functions and business capabilities — which 
then tie to strategy. 
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This provides a complete view — from conceptual to the physical operation and back 
to the conceptual view — of the new design as it rolls up to ensure that strategy is 
supported. 

In this progression of involvement, the project will first need to take advantage of 

1. Business Architecture and Business Architects to look at strategy and its 
impact on the business. It will then move to 

2. Process Architecture and Process Architects as the current business 
operation is defined and modified. The changes to the business will then 
require the involvement of 

3. Enterprise Architects to look at the business needs from an IT perspective. 

The participation of these individuals along with Enterprise Architects will need to 
be built into the project approach and plan, along with the differing roles of 
managers (senior through mid-level to line managers). 

To help guide management through this change process, the team should consider 
adopting a formal BPMS-based BPM project methodology. This can be internal if the 
company has one (IT methodologies like Agile do not count), or purchased if that 
makes sense. But the key is to create a consistent framework to base the project and 
its tasks on. This methodology should include formal change management activity 
that is meant to engage a broad part of the workforce and win their buy-in. 

The transformation project plan will be based on the tasks and guidance in the 
BPM/BPMS project methodology. This plan will be customized to fit the project, 
company standards, company culture, and financial realities. 

In defining the direction that will be taken in analysis and design, it is suggested that 
the project team identify the techniques they will use and where they will use 
them — Value Chain, Lean, Six Sigma, CMM, Activity- Based Costing, etc. 

But because it should be built for the project, the approach and plan must be 
understood by all, both discussed and debated, to make certain it is accepted. 
Governance then must ensure that everyone follows the plan and lives up to their 
commitments. 

The changes in the business strategy and business capabilities and their functions 
will now provide the basic requirements for the transformation. These become the 
Critical Success Factors. These requirements and Critical Success Factors are built 
into the approach and the project plan to ensure that they drive the analysis and 
redesign. 

7.4.1 Creating a change-ready operation 

While the requirements of the transformation and its Critical Success Factors set the 
stage for change, they do not provide the ability to actually change. 

Transformation must take place at all levels in the process or the business 
capabilities that are being changed as part of the project. Here a top-down approach 
should be considered because work that is performed today may simply not be 
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necessary tomorrow. The fundamental rethinking will question everything and 
propose new ways of doing business — including new automation and outsourcing. 
So, the business operation may become a mixture of work that is very different from 
today’s. In this "nothing is off the table” approach to transformation, the managers 
and project team will be challenged to "think outside the box" and leverage 
emerging concepts and technology to come up with new ideas on how the business 
could run. Part of this questioning and outside-the-box thinking will be based on 
BPMS-based BPM technology and approaches to both change and continuous 
improvement. 

But the key to real transformation is the creative application of knowledge on how 
the business actually works at all levels, including the market, legislation, and 
technology. This must be knowledge of both the current status in all these areas and 
any changes that experts are predicting. It is creativity that differentiates between 
teams and companies. 

The team with the most creative people will be innovative, and ideas will be very 
different from those of more traditional teams. Part of the difference is in not 
knowing any bounds. For this reason, it is suggested that people with 
transformation expertise, even from other industries, be added to the team. They 
tend to question different things and propose ideas from new perspectives. 

Given creativity and innovation, the team will be faced with looking at the operation 
in new ways. Many of the ideas will not be feasible. Many will simply not work. 

Many others will not be palatable in the company’s culture. But even in rejected 
ideas there is often a nugget of gold. These can add up and together allow the team 
to make design changes that they would otherwise not have considered. 

This questioning and learning makes the transformation project the start of building 
a change-ready operation. Regardless of how good the new design, like all other 
business designs, it will quickly become obsolete and not reflect the changing 
business environment. To avoid this aging, it will be necessary to add continuous 
improvement to the approach. Here the goal is to create an operating environment 
that learns and then applies that learning to evaluate the business for improvement. 

To achieve this, a transformation must be viewed as open-ended. The first 
transformation project will, of course, have an end-date and deliverable targets, but 
the project should not end there. This point should be viewed as the starting-point 
of its evolution, not an end-point. 

This approach allows the company to constantly view the operation as changing. In 
the past this was a scary concept. But today, in a BPMS-supported BPM operation, 
the change is less dramatic and less risky. It is more dynamic. In this way, the first 
transformation project sets the stage for continuous improvement and provides the 
embedded performance monitoring needed to constantly look for problems and 
ways to do things better. 

This will require a change in the way projects and business evolution are viewed. 
Today, open-ended projects are seldom tolerated — even ones that offer a series of 
delivery dates and benefits come to an end. But if a company wants to move to 
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continuous improvement, transformation never really ends. Once the initial 
transformation is implemented, the operation moves to an unending cycle of 
performance measurement, review, analysis, and change. 

7.4.2 Funding: Always a problem 

As noted, business transformation is change at a fundamental level, making it 
disruptive and difficult. Part of the difficulty is the cost of these projects. The funding 
required is always greater than that of an improvement project. The benefit 
calculation is also a lot harder because an improvement project will have a very 
narrow, specific set of objectives and, correspondingly, benefits. Transformation, 
being more strategic, should be viewed differently and should be funded differently. 
However, in today’s ROI-focused environment, the transformation will likely need to 
be justified the same way an improvement project is justified — that is, based on 
hard benefit estimate, not on strategic need. But this will vary by company and the 
project manager will need to work with the project sponsor to determine the 
funding view that makes sense in your company. 

The key is to work with senior business management, finance, and IT to create an 
approach and formula for determining benefit of transformation efforts. This 
formalized and approved approach is rare today, but it is recommended that it be 
considered before the transformation effort is requested. 

Funding should also be tied to the project plan. If the plan is based on a 
methodology, the project manager and sponsor will be able to estimate the work 
and cost more easily. It will also show how the funding will be needed (when, what 
for, and what will be delivered). This can change the way the funding is viewed. By 
aligning funding with deliverable and benefit over time, the investment will be 
spread and the benefit may well be able to offset the investment. However, if the 
initial phase or deliverable needs to cover all BPMS and IT investment, the project 
will likely not be approved. It is therefore important to work with IT and with the 
sponsor to see if there is a way to spread or offset the cost of the technology. 

Funding may thus follow a different approach than that used for improvement 
projects. The important fact is that the project manager will need to determine the 
approach and formula for looking at benefit in transformations. 

7.4.3 Understanding the goals of the transformation 

Language can be imprecise. Terms may be defined differently. In international 
companies, currency translation and other factors may also complicate the defining 
of goals, computing of value and benefit, and compliance with legal requirements. 
When projects are small, the impact of these considerations is limited. When 
projects are big, like a transformation project, the impact of these and other issues 
can be very serious. 

For this reason it is important to take the time to make certain that everyone has a 
common understanding of the goals, approach, measurement, and evaluation of the 
project’s success. If this is not done, the risks associated with the project increase. 
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This has historically been a key problem with outsourcers, where there are often 
language and definition barriers. But it doesn’t just affect outsourcing. It is seen 
constantly in everyday work and operations. It drives the ages-old issue of 
improving internal communications — "this is not what I meant" — "but that is what 
you said." It is also the reason that ABPMP urges everyone to begin a project by 
defining "common" and BPM terminology. For example, "customer" can have a great 
many meanings. "Process" is also a very misunderstood term; in one online BPM 
dictionary, the term "process" has more than 10 different definitions. The team and 
all those involved must have one common definition of any term. If not, 
misunderstandings will occur. Accent and language problems also play their parts in 
these misunderstandings. All must be considered in collaboration and 
communication. 

To offset this issue, it is important that time be spent up front in the transformation 
in workshops to bring everyone to a common understanding of the project, its goals, 
its terminology and its tasks. This will allow managers to know what to expect and 
to understand their role in the project. 

7.4.4 The resources: Different people with different skills 

As noted earlier in the chapter, transformation projects should be staffed with 
people offering a variety of specialized skills. These include Business Architecture, 
Enterprise Architecture, Process Architecture and Process Management, Database 
Architecture, Web Services, Data Management/Delivery and Business Operations 
Management. In some companies, Change Management can be added to this list. 
Although there are a lot of traditional business skills, BPM skills, BPMS skills, and 
technical skills on this list, the transformation projects require additional specialty 
skills. Transformation projects are big and require a lot of resources, both full- and 
part-time. These skills may include cloud computing, Lean, Six Sigma, BPM strategy, 
data consolidation, SOA, web application, customer experience, and more. 

It is therefore important to identify the source of any skills that may be needed so 
they can be added to the project team if needed. 

7.5 Transforming the business: reaching optimization 

The foundation for the transformation is set forth in earlier sections of this chapter 
(see, for example, 7.2). 

The keys in transformation are the targets (goals, standards, performance targets, 
KPIs and requirements) and the approach. Starting with the goals and requirements, 
the project team and all participants will need to have a common understanding of 
what they mean, and the expectations of all business managers, staff, and 
collaborative partners who are involved. This must be obtained through workshops, 
and consideration should be given to a test to ensure understanding of key concepts, 
goals, requirements, IT capabilities, etc. 

In addition, the approach will need to be augmented now that the foundation is in 
place and the project is starting. A lot of issues will have been listed in 
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transformation project setup. These are a good start, but the team will now need to 
deal with procedural issues, such as 

• How many of the assumptions made in considering the project were 
supported by management? 

• How many discovery teams will the project team be broken into? 

• Will the interviews be conducted by a single team member or by a pair — one 
talking and one taking notes? 

• Will there be a dedicated user or two, or will the team choose a broader- 
involvement approach and take a little time from a lot of people? 

• Will the business users receive BPMS training or will all modeling be done by 
the project team? 

• Who will be involved in creating the transformation governance and 
standards? 

• Where will the team find business rules — manuals, memos and 
interviews/workshops? Will any be pulled from applications systems? 

• What is out of bounds in questioning and consideration for change — is 
outsourcing in or out? Are new web applications in or out? Can departments 
be eliminated? 

• Will the team take a process perspective or an organization perspective? 

• Will the team use simulation modeling or workshop walkthrough to test the 
design? 

• Will there be a BPM or Business Architecture CoE (Center of Excellence) to 
provide guidance and standards? 


This is not an exhaustive list, merely some examples. The list continues with issues 
that are specific to your company and the areas of business in the project. 

In actually performing the transformation activities, the project team should be 
guided by the BPMS/BPM methodology the company has adopted. This 
methodology will provide a list of the tasks that need to be performed and their 
relationships, along with the data that must be collected for each group of tasks and 
the deliverables that should be produced in each of these task groups. The project 
manager will augment this methodology with company-standard formal project- 
management techniques and activities to create the transformation project’s plan. 
To customize the approach and methodology to the scope, complexity, and 
objectives of the project, it is recommended that the project manager work with the 
company’s BPM CoE and IT. It is also suggested that the project team involve 
Business Architecture and Enterprise Architecture at the points in the planning that 
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will need their support. The project plan and approach, once reviewed and accepted 
by these groups, should then be reviewed for formal acceptance by the executive 
committee. Following their acceptance, the plan should be published on the project’s 
web site and discussed in a workshop with all participants. This will help ensure 
that everyone understands the project, its approach, and its plans. 

The transformation project will then follow a common approach that is customized 
to the project. This reduces cost and risk while providing consistency. The project 
will start by moving through the methodology’s start-up task groups to defining the 
current business with the construction of a high-level "As Is" business-operation 
model. This model will be focused on the process(es) that will transform in the 
project and show the activities assigned/performed by each business unit in scope. 
This is a key part of the transformation. 

Note: Every transformation will have different drivers, goals, and scope. Some will be 
organizationally oriented and confined within a business unit or department. Others 
will be process oriented. The project plan will reflect the scope and goals, but they will 
both now define the "box" or limits of the models. 

This model will be broken into lower and lower levels of detail until a complete 
picture of the current business process/operation in scope is defined. Business rules 
and the applications that are used will be identified and the data used at each 
application "touch point” in the business will be shown. A variety of metrics (as 
defined as a standard by the project team and the BPM CoE) will be collected in the 
discovery process. If the project team will use simulation to test the new design — 
and this is recommended — the data needed will be identified and collected in this 
"As Is" discovery. The "As Is” models will be run in simulation to obtain baseline 
metrics. These metrics should be reviewed with the business managers and 
adjusted if necessary to accurately represent the current business. 

The project team will now need to create a high-level new or "To Be” design with 
anticipated improvement metrics in the modeling tool. Everything will be 
questioned, and innovation and "outside-the-box" creativity will be applied. While 
legal, financial, and reporting limits will need to be considered, aside from these 
limiting requirements (and others identified by executive management), there are 
no limitations to what the project team should consider in the transformation 
design. 

At this level, there is little detail on the actual operations. This level is, however, the 
most important level in the redesign because it is here that fundamental change is 
first a main driver in the redesign. This will set the stage for the detail design. If the 
project team is timid in the high-level design, little will change and the lack of 
creativity will guide the detail design as well. 

This high-level design will provide the framework for the detailed "To Be" 
operational design. By entering the models into the simulation application, the 
project team will be able to test the delivery of the higher-level transformation 
requirements and goals. To confirm the delivery of the expected transformation 
operation, the project team will walk through the high-level simulation with 
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executive management. All comments and observations will be used to finalized the 
design and create a final high-level simulation test. 

Once the high-level models have been accepted, the real work of the transformation 
will begin. 

These high-level "To Be” models will be used to create a series of detailed "To Be” 
models as the project team iterates through design options to find the best new 
design. 

Following a process-centric approach, it will now be necessary to look at process 
and the alignment between process and organization. 

Note: If the transformation is following an organizational approach, the project will 
not address entire processes (which are cross-organizational) and it will be necessary 
to determine the possible impact of changes on the downstream parts of the process 
that are not in the project. This assessment will help determine what changes can be 
made in the new design. This is a limitation related to an organization approach. 

Once the new "To Be" design is approved, construction of the new business 
operation can be planned. It is suggested that the project divide the new high-level 
design into parts that can each deliver a given part of the product. This creates a 
cohesive new design built as a series of related but separate construction projects — 
the same as is followed with sub-assemblies coming together to form the product. 

Each of these component parts can now be designed at a detail level. In this design, 
the same approach of questioning everything and being innovative should be 
applied. As with the high-level redesign, the new detail designs should be tested and 
iterated using simulation. Here, however, the detail designs should be approached 
both as individual transformation projects and as a part of a larger transformation. 
This allows each to be considered individually and also as they fit into the larger 
transformation design. Here each will receive input from other components and 
each will perform activity, and deliver data and product to the components it 
touches, as shown in the high-level design. This allows management to track 
improvement at the individual component level and at the project level. 

Of course, as the component designs are being planned, designed, tested, approved 
and constructed, IT will be provided with high-level support requirements and more 
detailed-level application interface, Java module, web service, database design and 
other specs. Simulation testing will be tied to the delivery of IT infrastructure 
changes and the needed interfaces, etc. This delivery will determine the final 
simulation testing schedule and the overall transformation implementation 
schedule. 

As all "final" simulation design tests are completed, the new design should be 
reviewed in a walkthrough with all the people who will work in the new business 
operation. Their "hands on" input may cause additional iterations, but the result will 
be an optimal result. If a BPMS is used, this new low-level design (business model, 
rules, data, screens (forms)) will be used to generate new applications that are 
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produced and executed within the BPMS environment. These will be tied to the IT- 
built support (Java modules, etc.) to create a complete solution. 

7.5.1 Creating a Win-Win outcome 

Win-Win means everyone wins. The company must gain benefit first of all. But it 
cannot be the only winner. Managers at all levels must individually win and so 
should staff members. If this is a key goal of the project, acceptance of the solution 
will be likely and risk will be minimized. 

Winning, however, has a lot of different definitions. It may mean that someone is 
judged as having performed better than expected. It may mean that workload is 
reduced. It may mean that the culture changes to one where people are treated well 
and not afraid of being fired in a downsizing. In attempting to create a win-win 
solution it is important to talk to people and see what they hope to get out of the 
project. This is where HR (Human Resources / Human Capital, etc.) comes into the 
transformation project. 

While this may seem simple, in union shops it is not. And in today's highly regulated 
business world with local HR law and reporting mandates, dealing with people 
issues is anything but easy. So, HR must be involved in any consideration of a win- 
win scenario. 

But even if difficult, a transformation project must look at fundamental changes to 
work and everything having to do with people. The simple fact is that any company 
and any process is a social operation. People work together, interact, play politics, 
and make things work — they find ways around problems every day. So, the people 
and cultural side of the transformation are critical to success. 

7.5.2 The status of Legacy technology: help or limit to transformation 

IT will either be a helping or a limiting factor. Even if everyone in IT including the 
CIO is eager to help and join in the transformation, in many companies, cost-cutting 
has limited what IT can do. Legacy applications and a legacy IT architecture can 
serve to limit the types of things that can be considered. If a possible change cannot 
be supported without a major investment in IT, it may need to be dropped from 
consideration. 

As we keep stressing, transformation requires rethinking and a radically different 
approach than was taken in the past. Otherwise, you may be simply doing more 
quickly the things that have limited your success. And, while this may be the case, 
there is also reality. Some companies have funding constraints, some have IT 
constraints, some have union constraints, and the list goes on. These realities must 
be considered in any solution. So, while creative thinking is needed, it must also be 
done within the bounds of reality. 

Here the project team may still consider a solution that ignores certain limitations — 
after discussion with executive management: it allows the project team to look at 
differing time-based targets. In each target the limitations and assumptions that are 
built into the transformation design change. As an example, the end-target design 
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might be based on the elimination of, or spacing of, financial constraints. The project 
team will then create a final design and back off to add in given constraints at 
different time periods. Because a transformation project is multi year, it can allow 
for change in the constraints over time and build different solutions that will move 
from one constraint-base to the next, with less constraint over time. This is 
especially helpful if the IT architecture or infrastructure will be a constraint: it may 
change as new hardware, software, or communications are added. 

In this case, the project team should work with the CIO and lay out a series of time- 
related improvements to the IT capabilities. It is then possible to coordinate the 
delivery of different phases in an increasingly flexible and capable series of solution 
releases. 

7.5.3 BPMS and transforming the company 

Many today believe that true transformation cannot take place without the support 
of a BPMS. The reason is that, while a design can be built using simple tools or even 
paper, it will not be as comprehensive as it could be. Simply stated, it is impossible 
to keep up with the data that is collected in a transformation and the almost daily 
changes to it. 

Also, without automation it is difficult to simulate an operation, and almost 
impossible to control its iteration. That is why IT and others have historically taken 
the position of going above and beyond to make certain they get the 
requirements/specs right the first time. But we all know that while that is the goal, it 
is seldom reached, particularly in complex projects. The business simply changes 
too fast for any traditional IT-development or system-improvement project to keep 
up with it. 

But the biggest reason for using a BPMS is the ability to rapidly generate 
applications to both improve the way the operation is monitored and controlled, 
and provide task automation. This reduces the burden on IT (create interfaces/data 
access, web services, Java modules, etc.), and supports an ability to change rapidly 
through iterative designs and testing. It is this ability to 
change/monitor/analyze/iterate that delivers optimization and continuous 
improvement. This is also the tool that allows a learning organization to leverage 
lessons, eliminate problems, and reduce risk. 

7.5.4 Redesigning the operation: Process level, business unit workflow 
level, leveraging technology 

As we have said, transformation is not about doing the same things better. It is not 
simply about improving efficiency or eliminating error. It is about the customer and 
taking a new look at the business operation. And, it is about taking this viewpoint 
and radically rethinking the way the business delivers service. This is a critical point 
in understanding transformation and in redesigning the business. Without it, you 
are not doing transformation. 
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Businesses evolve toward mediocrity over time. Constant small changes and the fact 
that change has historically been organizationally limited cause processes to 
become unorganized, weak and ineffective. They are often brittle and break easily. 
Improving them has helped by putting new patches on the old ones. 

But little has happened to make them serve the customer better or make the 
company more competitive. Eventually, the operation starts to break down and 
"white space” manual work around effort becomes common. At this point the 
operation is broken. It may operate and work will be done, but the effort to make it 
work is extraordinary and the risk of any change is high. 

Transformation is a new look at the processes and the company. It is about thinking 
big, unfettered. And it is about changing at all levels (process, subprocess, business 
unit, and workflow) simultaneously in a way that looks for the best way to serve the 
customer and then works inward from the customer interaction to optimize how the 
processes work. This perspective is often new to companies who are used to looking 
inward to improving the operation and driving out cost by improving efficiency. 

Example: How many people like to call companies to order or request something, when 
they are likely to speak to someone they can’t understand and who really cannot help 
them? How many people really like calling to talk to a computer that gives them five 
choices — none of which seen to be the one that will help them? And, how many like 
going through the layers of automated questions to place an order or find 
information? I, for one, go right to the 'talk to someone’ option. 

As a starting point in any transformation design, put yourself in the customer’s 
position, not in your company's position, and eliminate all the things you and the 
project team hate when dealing with a company. That is a good starting point. Then 
work inward to eliminate what you hate and correct the deficiencies that stop 
interaction the way you would like to do it. 

Focus groups and customer questionnaires are good tools to help in this definition 
of interaction problems. Although the customer perspective is only one of many 
drivers, it is an important one and it affects all levels of the new design. 

7.5.5 Performance monitoring and feedback to solve problems 

Most companies have some form of manual and automated performance monitoring 
and reporting. But the question that must be asked is, does it measure the right 
things? Much of the reporting in companies has evolved over a great many years. 
People just keep getting the reports and, when asked, acknowledge that many are 
useless or provide a limited amount of information. But it is so onerous to change 
these reports in most companies that business managers live with what they have. 

During any transformation, this situation must be reviewed and changed. Reporting 
must be made useful. To do this, it must be built into the new business workflow 
and management designs. 
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If a traditional approach of creating requirements/specs from the new design and 
giving them to IT to build applications/interfaces, etc., is used, the reports will be 
built following the normal IT methods. 

If a BPMS is used to support the creation of the new transformation business design, 
it will be possible to generate performance-monitoring capabilities from both the 
parts of the business that will execute within the BPMS (see chapter 10, BPM 
Technology) and from legacy application data. This allows the BPMS operation to 
monitor activity and then anticipate outcomes based on given rules. With this 
ability, managers have a new level of performance monitoring and reporting. 

Transformation is a chance to rethink not only what information really will be 
helpful, but also how it should be delivered — paper, reports delivered on screens, or 
summaries on automated dashboards. All have a place and the options are growing 
with iPads, smart phones, etc. The key is to understand each option and then work 
with the business users and IT to define the right options for the needs. 

Through this approach, it is now possible for managers to keep track of what they 
are interested in monitoring and to instantly send guidance as alerts and warnings 
are received. The technology is delivering new capabilities, and both performance 
monitoring and measurement (evaluation) can now provide new ways to deliver 
information and react to it. 

7.5.6 Delivering flexibility and speed of change: Arguably more important 
than savings (strategic use of BPMS/BPM vs. tactical short-term benefit) 

Using a BPMS in a transformation project is a commitment to the tool and the 
approach. The new design will execute within the BPMS — it cannot be separated 
from it. So, using it represents a strategic commitment to the tool and the changes it 
supports. The reason is that transformation implies a broad-based change, and 
whatever technology is used will affect a significant part of the business operation 
and the IT infrastructure. Because transformation and continuous improvement 
(which will hopefully be a goal of the project) require long-term commitments, the 
technology that is used represents a strategic commitment in the business area 
that’s to be transformed. 

A BPMS offers significant advantages over traditional technology. The advantage 
that is a true game changer is the generation of applications. Today BPMS tools have 
evolved to the point where they can generate industrial-strength applications (see 
chapter 10, BPM Technology). Other technology that interfaces with the typical 
BPMS can offer additional speed in legacy-application interfacing and web-service 
design/delivery. Together they provide an ability to change very fast by modifying 
business models and rules, redefining forms that design screens and reports, and 
then regenerating applications. 

This ability to regenerate applications is the foundation for iterative design and 
testing. Whether the design is simply iterated with built-in performance monitoring 
that provides results reports or iterated using a simulation modeler, the bottom line 
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is that the BPMS-supported new business operation can change quickly and with 
limited risk — for a low cost. 

This is the true advantage of a BPMS. 

7.6 Sustaining Optimization 

Transformation is the first step into a new operating future. It is not the last one. 
Beyond transformation lies continuous improvement. 

Traditionally, once a major change has occurred, management believes that the 
business operation can be left alone for a considerable time. In BPM, that 
perspective needs to change to adopt a policy of continuous improvement in all 
areas that have been transformed. 

Once optimized, the trick is to sustain an optimal level of performance as the 
business and the market change. In chapter 5, the Evolutive Management concept 
was introduced. This is an approach that recognizes that the business will evolve. 
There is no question about that: the question is whether it will evolve through 
management direction or simply evolve uncontrolled, with management playing an 
unending catch-up game. 

Transformation, if performed the right way, will have eliminated problems, waste, 
and cost, while evolving the business to support faster response to market 
opportunities and legislative requirements. In some cases, performance 
measurement and reporting will have been put in place to help the operation find 
and focus on smaller changes as it moves from transformation into a new operation. 
If continuous improvement is adopted, management will once again focus on 
improvement to resolve problems and address market and legislated requirements, 
in the move to sustain the state of optimization. This goes far beyond focused 
improvement and moves the operation to an environment of continuous evolution 
with the goal of sustaining a state of operational optimization. 

But because optimization is a moving target with a constantly changing set of 
characteristics and values, it should be realized that optimization can never be 
maintained for long. The business environment in which companies operate 
changes constantly. Because the changes are different all the time, they constantly 
affect different parts of the business — at times even those that have been 
transformed. 

This means that, to approach optimization, the business must be able to change 
quickly enough to adjust to a variety of drivers and events in a matter of days or at 
the most weeks. In this reality, optimization may be achieved, but it will be a fleeting 
victory, for as soon as it is achieved, the company will need to change to keep up 
with the next change in the changing business world. 

To keep pace, the company must adopt a posture that promotes continuous 
evolution. Here the business, once transformed, never stops changing. In this 
environment, the ability to change quickly is more important than any single 
outcome or change. The reason is that any outcome will be valid only briefly and the 
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business will need to move to the next iteration of its operation as quickly and with 
as much control as possible. This type of constant evolution was not possible before 
BPMS-supported BPM — it simply took IT too long to change applications. 

With the ability of a BPMS to generate applications, the past concept of continuous 
improvement is changing to support continuous iterative business change. But 
BPMS-supported BPM is only part of the answer. 

Business transformation can set the stage for a new business approach — one of 
constant evolution to optimization. This will require a new understanding of what 
BPMS-supported BPM now allows to be possible. The challenge to the 
transformation team, the BPM CoE, and the BPM industry is to help management 
understand this new approach and to adopt it. 

7.6.1 Commitment to continuous improvement 

When everything is going well, the operation has been transformed, and the level of 
performance approaches optimization, it is easy to forget how that happened and 
tough to be committed to maintaining that level of service. 

Example: A major health insurance company implemented a transformation effort in 
claims processing. The people on the transformation team were trained and 
management was committed. The effort achieved all goals and exceeded expectations. 
The project team members were promoted and either ran or assisted managers in 
running the transformed areas. Things were great for several years. Improvements 
were found and made and the operation was fairly optimal. But as the original 
transformation team members were given different jobs or left the company, the 
commitment to continuous improvement became less and less. Finally at the seven- 
year mark, the business operation was once again operating at a mediocre level and 
was in trouble. 

Given the investment in transformation, continuing to insist on a program of 
continuous improvement just makes sense. But this commitment must transcend 
any individual or it will slowly be lost as new people replace those who understand 
what the commitment gives them. 

7.6.2 Evolving the process 

As the business changes, so will its needs. As noted, these changes will drive 
continuous improvement, but it will be at the improvement level and not at the 
transformation level of change. For most things that will be fine. However, the 
business must evolve with the industry, the marketplace, advances in IT technology, 
advances in production technology, new products that the company will offer, and 
much more. At some point, these drivers may be so significant that another 
transformation will be needed. This transformation will be different from the first, 
which created the current transformed operation. 

In the future, the transformations will be a redesign with a wider scope than the 
improvements. The models, rules, forms, and other information will be in the BPMS 
and transformation will simply be a bigger improvement effort with the focus of 
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radically rethinking the business based on the drivers. Disruption should be much 
less and risk much lower. Everything will be in place and reusable. This eliminates 
the project start-up "As Is" modeling and starts with simulation-based redesign. 

A BPMS-based BPM environment is designed to change and help the business 
evolve. Care must be taken in putting the people and reporting in place to direct and 
control this evolution. 

7.6.3 Continuous improvement 

Often touted and seldom truly delivered, continuous improvement, when performed 
in a BPMS-supported BPM environment, becomes feasible and beneficial. 

The problem with past attempts at continuous improvement has not been with the 
identification of a need or the redesign. Six Sigma and other evaluation techniques 
have been mostly successful in identifying the need, and Lean and other 
improvement techniques have produced good new designs. And, applying these 
techniques at the improvement level seems to work much better than at the 
transformation level. So they are being applied at the right level in trying to produce 
improvement. 

The problem comes with the creation and implementation of the changes. This 
problem is timing. Today in most business environments, changes take a long 
time — especially when the change involves IT and changing applications or building 
new ones. Because the business need is changing quickly, it has been difficult or 
impossible for most companies to build and implement changes quickly enough for 
them to be effective in moving toward optimization. 

Clearly any change that takes months or longer from the time it is requested to the 
time it is deployed will be out of date when it is delivered. The proof of this is in the 
requests for further changes that accompany the delivery of most IT support. 

Continuous improvement, to be effective, must be capable of delivering very fast 
changes that include the business operation and IT. Building this environment is 
part of a commitment to continuous improvement because it can be reused by any 
part of the business. Building it requires a BPMS tool and a commitment to 
architecting the IT infrastructure to open data access and increase the speed of 
delivering applications and interfaces. It also requires a commitment to 
investigating and adopting new technology and new business approaches. 

When this is in place, true continuous improvement can be put into operation. 

7.7 Key Concepts 

• Transformation is the fundamental rethinking of the business operation. 

• Transformation is both invasive and pervasive, and is both a large and 
expensive project. 

• The scope and level of change in transformation requires skills from multiple 
disciplines. 
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• To control transformation-level projects, the work should be guided by a 
formal methodology. 

• Transformation-level projects should use a BPMS and follow a BPM-based 
approach. 

• Transformation provides the opportunity to move the business to continuous 
improvement. 

• To succeed, transformation requires the involvement and support of the 
executive team and the business managers and staff who will be affected — in 
scope. 

• Funding is always problem in large projects. The transformation can be 
designed as a whole and deployed in high-profile, high-benefit parts in order 
to start realizing benefit sooner. 

• Change management must be considered to help the project win business 
manager and staff acceptance. 

• A formal, but evolving, change management plan should guide the approach 
and staff interaction. 

• Performance monitoring, measurement, and evaluation should be built into 
the new business design with the involvement of the business managers and 
staff who will be monitored. 

• The end of the transformation is the beginning of the continuous 
improvement cycle for the transformed business operation and process. 

• Transformation and continuous improvement will change culture and should 
create a partnership between management and staff for future change. 

• Management should be committed to innovation and "outside the box" 
thinking in the transformation. 
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Foreword by Andrew Spanyi, Managing Director, Spanyi 
International Inc. 

This chapter addresses some of the key organizational factors that are relevant as a 
company moves towards becoming a customer-focused, process-centric enterprise. 

The principal concept is that an organization needs to introduce and sustain 
accountability for the flow of work that crosses traditional organizational 
boundaries in creating value for customers and the company. 

The relevant organizational approaches typically include changes in work 
processes, organizational structure, roles and responsibilities, performance 
measures, values and culture. The changes in organizational structure do not 
replace traditional structures based on functional, geographic, or product 
disciplines. Instead, a process organization represents an overlay on a traditional 
organization design intended to create greater emphasis on customer focus and 
process orientation. 

Changes in organization structure through the introduction of roles such as process 
ownership and a BPM Center of Excellence need to be supported by the right 
models, measures, improvement methods, and aligned recognition systems. Simple, 
visually compelling and relevant process models, customer-focused measures, 
integrated improvement methods, and aligned recognition systems all serve to shift 
company culture from a hierarchical view to a customer-focused, process-based 
view. 

The role of measurement is crucial in this regard. Process-oriented companies 
measure what matters to customers. The most common of the customer-focused 
measures include perfect order delivery (as defined by The Supply Chain Council), 
perfect new product introduction and first-time-right responses to customer 
inquiries and complaints. 

Establishing accountability for process performance is another cornerstone of a 
customer-focused, process-centric enterprise. In spite of the existing literature and 
no small amount of fanfare around the importance of process ownership, 
organizations often stumble with success in process ownership in some or all of the 
following ways: 

• Process owners are appointed at middle management levels with responsibility 
for processes of small scope and are not supported by executive process-owner 
appointments for the improvement and management of the firm’s end-to-end 
processes 

• There is a lack of adequate and continuing training for, and education on, the 
role of the process owner 

• The role of the process owner is divorced from the fundamental management 
framework of the firm, and process owners lack a clear voice in making 
decisions around resources and priorities. 

An integrated approach to improving performance through a customer-focused, 
process-based view of the enterprise is another key element in becoming a process- 
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centric enterprise. This requires integration in the various improvement methods 
used by an organization, including approaches such as Lean, Six Sigma, Continuous 
Process Improvement, Reengineering, and technology-enabled BPM initiatives. 
While such integration involves a greater investment in training and generally 
requires more effort, the resulting benefits can be significant. 

The journey to enterprise-wide process management involves the definition of a 
company’s end-to-end processes (typically 5 to 10), measuring performance from 
both the customer’s and the company’s points of view, designating process owners 
with responsibility and accountability for process performance, selecting two or 
three processes for improvement action, capturing early wins in each selected 
process, and sustaining gains through ongoing management of the firm’s end-to-end 
processes. This cycle is then repeated until the entire operations of the firm have 
been optimized. 
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8.0 Introduction 

Each business is different, and the nature, amount, and pace of change in a business 
are dynamic. A business process management focus changes the way executives 
think about and structure their institutions. Historically, most companies have been 
structured around functional, geographic, or product disciplines. Few companies are 
structured around their business processes. As institutions reach new levels of 
process maturity, new skills, management structures, and ways to align, motivate, 
and reward employees may be introduced. This chapter helps build an 
understanding of the nature of what these changes may include, so that Business 
Process Management Professionals can anticipate, plan, prepare, and guide the 
business through the transition to a process-driven enterprise. These changes 
include 

• Organizational approaches to consider as businesses introduce and mature in 
the discipline of managing their business processes. Changing organizational 
approaches can be challenging and can include changes in work performance 
processes, organizational structure, roles and responsibilities, performance 
measures, values, and culture. Essentially, everything about the company, 
perhaps even how it defines itself, is subject to change. 

• Lessons learned from implementing Enterprise Resource Planning (ERP) 
systems: how organizations have been affected, leading some to become 
process-driven. 

• Specific roles and responsibilities played by individuals in a process-driven 
organization. 

• Process-specific governing bodies, which lead to successful process 
improvement implementations, according to field practice and research. 

• Developing a Business Process Management Process Center of Excellence (BPM 
COE). 

8.1 The Process-Driven Organization 


The process-driven organization is an enterprise that is 
structured, organized, managed, and measured around its 
primary business processes. 


8.1.1 Considerations in Managing Primary Processes 

Many companies discover that to be effective in managing their primary business 
processes, they must assign clearly defined accountability for the design, 
documentation, maintenance, upkeep, and long-term health of these processes. New 
roles, responsibilities, relationships, and organizational structures may be 
contemplated. This often leads to a significant change in management focus and the 
way work is performed, developing from a more traditional structure, focused on a 
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particular resource or business function, to the cross-functional performance of the 
end-to-end processes that deliver value to customers. 

8.1.2 Contrasts between Traditional Management Structures and the 
Process-Driven Organization 

Traditional management structures involve hierarchical resource management that 
delegates responsibility from one level of management to the next, with ultimate 
accountability assigned to the organization’s individual stakeholders. This 
delegation is expressed as a downward managerial focus on command and control 
of individual workers who have responsibility for specific sets of tasks. 

In contrast, process-driven organizations assign accountability horizontally, to all 
functions, for delivery of value to the customer. Process focus involves process 
design, documentation, measurement, and continuous improvement. Rather than 
command and control, process managers may find themselves coaching, advocating 
for, and supporting a group of professionals who actually perform or execute the 
process. 

A process-driven organization does not mean that process is the only dimension of 
management, performance measurement, or organizational structure. An integrated 
approach to performance improvement must take into account the organization as a 
whole, inclusive of process and the role of the individual with respect to the process 
and the organization. Although this concept has been discussed in depth in 
Improving Performance: How to Manage the White Space in the Organization 
Chart, by Geary A. Rummler and Alan P. Brache, it cannot be emphasized enough 
that this is the fundamental premise behind the process-driven organization and the 
organizational structures that support it. 

8.1.3 Rummler's Performance Matrix 

Rummler suggested using a performance matrix to illustrate and integrate the 
multiple levels of an organization and its concerns. This is a 3 by 3 matrix (see Table 
24) that covers the scope of the approach and indicates the three levels of an 
organization and the concern of each level. 4 


Level of Organization 

Concern at this Level 

Organizational 

The organization as a whole 

Process 

The specific processes the organization uses to 
accomplish work 

Job or Job Performer 

Concrete activities that people and systems perform 


Table 24. Concerns at 3 levels of organization 


4 This is another example of levels of an organization and processes previously discussed in chapter 
3, on process modeling. 
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8.1.4 Performance Matrix Presents an Integrated Approach 

At each level, the assumption is that organizations: 

• Define goals and measures, and create designs for achieving their goals and 
measures, and 

• Establish management practices that assure that the designs achieve the 
desired goals and measures. 

The table below illustrates the concept of an integrated approach to performance 
improvement. The primary point is that the matrix stresses an integrated approach 
and the dynamic interaction among all the levels and the nine variables in the 
matrix. 


Level 

Goals & Measures 

Design & 
Implementation 

Management 

Organizational 

Level 

Organizational 
Goals & Measures 
of Organizational 
success 

Organizational 
Design & 
Implementation 

Organizational 

Management 

Process Level 

Process Goals & 
Measures of 
Process success 

Process Design & 
Implementation 

Process 

Management 

Job/Performer 

Level 

Job/Performer 
Goals & Measures 
of Success 

Job Design & 
Implementation 

Job/Performer 

Management 


Table 25. Rummler's Performance Matrix 5 


8.1.5 Results of Deploying a Performance Matrix 

Organizations that have put into practice the concept of the performance matrix 
have made a significant transition in the transformation to a process-driven 
enterprise. Acknowledging the role of process in an organization seems trivial, but 
integrating process into the organization’s goals and measures and integrating the 
individual’s performance into the process and the organizational levels is not trivial. 
Often, the functional roles and responsibilities conflict within the realm of the 
Performance Matrix. Financial, market, and other performance measures remain 
important, as do functional and product skills. Some organizations may leverage 
hybrid structures, which include a process dimension combined with functional, 


5 Improving Performance: How to Manage the White Space in the Organization Chart, 
Geary A. Rummler, Alan P. Brache, 1995 
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product, market, or geographic dimensions. Others may take a more aggressive leap, 
structuring themselves almost entirely around processes. 

8.1.6 Process Culture 

A "process culture" exists when the business’s processes are known, agreed on, 
communicated, and visible to all employees. Characteristics of a process culture 
specifically include 

• General agreement on what the business processes are 

• Understanding of how business processes interact and affect each other 

• Clear definition of the value each process produces 

• Documentation of how each process produces its results 

• Understanding of what skills are required for each process 

• Understanding of how well each process performs 

• Ongoing measurement of process performance 

• Management decisions based on process performance knowledge 

• Owners of each process having accountability for process performance 

• Organizations that orient themselves to process understand 

• The need to change their management approach to incorporate process, and 

• The roles to manage process in their organizational structures. 

8.2 From Hierarchical Structures to the Process-Driven 
Organization 

The legacy of managerial structures in functionally oriented companies is typically a 
departmental hierarchy, where managers are responsible for workers performing 
tasks related to a particular resource or business function. Groups of workers are 
combined into divisions or departments, each adding layers of management and 
control. In large enterprises, these departments are often grouped by product, 
market, or geography. These "silos" of resources are represented on a common and 
familiar organizational chart, as in Figure 58. 



Figure 58. Organizational Chart (example) 
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8.2.1 Historical Origins of the Traditional Hierarchical Organizations 

There are many problems with the traditional vertical organizational structures. 
However, at one time, these structures worked because that was how the actual 
work was structured. The best example of this is the early days of auto 
manufacturing when companies like Ford were vertically integrated and every 
employee was "specialized" to do the work of their particular area, whether on the 
assembly lines or in casting steel for autos. Measurements were at the job level, 
expressed as output of, for example, units per day. Relating this to Rummler’s 
performance matrix: 

• The job performer output was units/day, 

• The vertical process (functional orientation) was manufacturing, and 

• The output was translated into revenue and costs on the income statement. 

8.2.2 Impact of ERP and ERP Systems on Organizational Structure 

As company growth strategies changed, so did labor strategies. The de- 
verticalization of many industries led to different organizational structures and 
business models. What hadn’t changed for every company was the functional 
orientation and approach to work in organizations. It wasn’t until the advent of 
Enterprise Resource Planning (ERP) systems in the mid 1990’s that organizations 
were forced to consider their orientation to process. ERP systems offered a 
standard, integrated alternative to the existing functional processes by transacting 
horizontal processes that were enabled through the ERP technology. There are 
many stories and examples of companies that invested a lot of money on ERP 
implementations with correspondingly high failure rates for ERP implementations, 
but the fact remains that the transformation imposed by ERP systems was one of 
process and not one of technology. Companies that were hugely successful were the 
ones who took a process-oriented approach to the transformation. The important 
point to note is that ERP, like it or not, was a technology disruption-point that forced 
companies to be more process oriented. ERP, by its very nature, demands 
horizontal, cross-functional processes such as procure-to-pay, order-to-cash (order 
fulfillment), concept-to-product (product development), and recruit-to-retire 
(human resources management) into value streams that require horizontal 
management. Table 26 lists examples of value streams and the typical ERP cross- 
functional names. ERP system modules typically take on the cross-functional names 
provided by the vendor. 


Value Streams 

Typical Cross-Functional 
Names 

Prospect to Customer 

Customer Engagement 

Order to Cash 

Order Fulfillment 

Manufacturing to Distribution 

Operations & Logistics 
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Value Streams 

Typical Cross-Functional 
Names 

Request to Service 

Customer Service 

Insight to Strategy 

Strategic Planning 

Vision to eBusiness Enterprise 

Enterprise Management 

Concept to Development 

R&D, Product & Service 
Evolution 

Initiative to Results 

Implementation Execution 

Relationship to Partnership 

Strategic Partnering & 
Outsourcing 

Forecast to Plan 

Budgeting, Outlooks & 
Forecasting 

Requisition to Payables 

Procurement/Vendor 

Management 

Resource Availability to 
Consumption 

Resource Management 

Acquisition to Obsolescence 

Fixed Asset Management 

Financial Close to Reporting 

Finance & Accounting 

Recruitment to Retirement 

Human Resource Management 

Awareness to Prevention 

Quality & Safety Management 


Table 26. Cross-functional names given to value streams 
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8.2.3 ERP Processes Changed Businesses to Process Organizations 



Procurement 


Finance 


i Order Fulfillment" 


■ Product Development* 
■Capacity Management" 
™ Customer Service^ 


Supporting Processes 

Human Resource Management 
information Technology Management. 
Facility Management, etc. 


Figure 59. Cross-functional relationships in an end-to-end process 


Since ERP processes are "pre-designed,” it wasn’t long before management of a 
company’s core business processes transitioned to a new, horizontal focus in the 
organization structure. These cross-functional processes required a new 
organizational orientation in which accountability and ownership of process 
performance needed to be explicit (see Figure 59). The addition of new 
responsibilities to existing roles within functional organizations created a process 
dimension governed by the role of a process owner. 

In terms of Rummler’s performance matrix, this new role requires integration of the 
job or job performer into the horizontal process. For example, order to cash 
necessitates a team orientation to the process where multiple jobs and job 
performers are up and downstream to each other before the final output is 
delivered to the customer. 


8.3 Process Management Roles 

Process-driven organizations in all stages of development include individuals who 
support the execution of process improvements: 

• Process owners 

• Process managers 

• Process analysts 

• Process designers 

• Process architects 
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• Business analysts 

• Subject matter experts 

• Executive sponsors 

• IT professionals 

• Change management professionals. 

8.3.1 Process Owner 


A process owner has the ongoing responsibility and 
accountability for the successful design, development, 
execution, and performance of a complete end-to-end business 
process. Process ownership can be a full-time responsibility or 
an added responsibility such as a line or staff function. 


Characteristics and Responsibilities of Process Owners 

Some companies may label the process owner role differently. For example, titles 
such as process leader, process manager, and process steward are often used. In 
addition to the title, the substance of this role may also vary. Process owners are 
likely to be individuals at an executive level, typically VP or higher, who have 
common responsibilities across vertical silos. They may have direct or indirect 
authority over strategy, budgets, and resources. Their scope of responsibility may 
vary. 

Process owners usually are those concerned with end-to-end business processes 
that directly deliver value to the customers of the organization and have enterprise- 
level responsibility for the performance of the process as it relates to and impacts 
the balance sheet and income statement. Depending on the type of process — for 
example, recruitment to retirement — they may be 'support process’ owners who are 
concerned with the processes that support the organization’s primary business 
processes, such as human resources, financial, or information technology processes. 
They may be subprocess owners concerned with sub-components of an overall end- 
to-end business process. 

The process owner role usually involves other duties, such as chairing 
transformation efforts, integrating process results with those of other process 
owners, advocating for process priorities, benchmarking process performance, or 
coaching process performers. Process owners may also have other roles in the 
organization, such as functional or departmental management. Whatever the title, 
authority, or scope may be, all process owners share a unique accountability for a 
business process. 

Some common characteristics of process ownership include: 

Accountability and responsibility for process design — Process owners may 
share decision rights relating to the process design with other managers or 
participants. However, they are accountable for the overall integrity and integration 
of the process design. Process design may be iterative, with a goal of continuous 
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improvement involving incremental improvements to tasks and activities, or it may 
require redesign of the entire end-to-end business process. 

Accountability for process performance — Process owners may manage the 
process, i.e., how work gets done, but not necessarily the people who perform the 
work. Managing process performance involves developing a strategy for the 
process, setting performance goals and objectives. It includes ensuring that 
resources and skills are in place, measuring and communicating actual performance 
against targets, and using this feedback to continuously reset goals and objectives. 
Process owners initiate process transformation efforts and define incentives, which 
ensure that the process continues to deliver value to its customers. 

Advocacy and support — In order to ensure that proper resources, training, 
incentives, and executive attention are allotted, process owners may need to 
manage communications and advocate for the processes under their care with 
executive management, customers, suppliers, participants, and other internal and 
external stakeholders. They may find that they must operate through influence 
rather than authority. Inevitably, even the most professional and successful teams 
encounter problems with each other, unanticipated demands, exceptional 
circumstances, design problems, or changing customer requirements. As process 
owners continuously monitor results, they must also investigate and resolve 
problems. 

First Process Improvement Projects Can Generate a Process Owner 

In organizations whose process cultures are less mature, the first appearance of a 
process owner could be a project manager responsible for a process improvement 
effort. These individuals typically have responsibility for a project outcome, such as 
improvement to a business process, but lack direct control over resources, policies, 
and budgets. Nonetheless, the project manager is responsible for gaining 
cooperation among many disparate groups within the organization, adhering to the 
definition of project delivery methodology, designing and implementing the 
processes, and managing change to achieve an overall process improvement. 
Throughout the project delivery process, project managers may monitor and control 
process operations to ensure that the scope of the project conforms to the project 
objectives. Projects, however, are temporary endeavors with discrete, finite 
outcomes and deliverables. 

Organizations whose process cultures are more mature have realized that process 
management requires ongoing support, maintenance, and nurturing; they institute a 
process owner as a critical and permanent component of an enterprise’s 
organizational structure. 
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8.3.2 Process Manager 


A process manager actually performs and coordinates the 
work on a process or processes. Process managers are involved 
in measuring and monitoring process metrics and driving 
continuous process improvement. 

Process Manager Responsibilities 

The process manager bears accountability and responsibility for process 

• Performance, efficiency and quality 

• Supply of the necessary resources 

• Control by prioritizing, controlling and escalating process needs 

• Co-ordination of the individual tasks and the allocation of resources 

• Results measurement and analysis, and 

• Implementation of required changes for improvement. 

8.3.3 Process Analyst 

Process analysts manage process transformation projects, lead process discovery 
and design workshops, coach process owners, and measure and report on process 
performance. Process analysts typically have a great deal of skill in documenting 
and understanding process design and performance patterns. They provide analysis 
and assessment of current processes, evaluate alternate process design options, and 
make recommendations for change based on various frameworks. Their findings 
provide insight for process integration, design, and structure. This role is often 
combined with the role of the process designer. 

8.3.4 Process Designer 

Process designers have significant process knowledge and design new business 
processes, transform existing business processes, and implement plans. Designers 
typically possess analytical and creative skills as well. They use visual and 
mathematical models to describe each step in a process and the organization of 
work. A process designer ensures that the process design aligns and complies with 
the overall business goals and policies. 

8.3.5 Process Architects 

Business or process architects may function in a business or technology role. 
Depending on the orientation, they may be focused on managing business 
performance or on mapping technology to business operations. Process architects 
are responsible for 

• Developing an enterprise business architecture blueprint, along with 
corresponding value-stream process metrics 

• Ensuring alignment among business needs, business architecture, and 
information technology architecture 
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• Developing and maintaining a repository of reference models and standards 
with regard to a company’s products and services, business processes, 
performance measures, and organization. 

Process architects are engaged in business process analysis and transformation 
initiatives. Their involvement may be from a standards and compliance perspective, 
or they may serve as subject-matter experts (SMEs) to advise the team on the 
company’s process methodology. Through the analysis of business process 
architecture, companies identify opportunities for market advantage, business 
integration, and various internal process initiatives. 

8.3.6 Other Key Roles 

Business Analyst 

A common role in process change initiatives is that of business analyst (BA). BAs are 
responsible for analyzing the information and technology needs of their business 
clients to help propose information and technology solutions. They may facilitate 
meetings to assist the project team in analyzing current technology mapping or they 
may be involved with business operations and designing new information and 
technology functions. Within the systems development life cycle, the BA typically 
performs a liaison function between the business side of an enterprise and the 
information technology department or external service providers. Common 
alternative titles are business systems analyst, systems analyst, and functional 
analyst. 

Subject Matter Experts 

Many process improvement projects or process management teams include what is 
commonly referred to as "subject matter experts" (SMEs). These individuals are 
typically people who have a deep understanding of certain business functions or 
operations, often possessing years of experience as a participant in business 
operations. They provide input on the current process and assist in designing new 
processes. They may have institutional knowledge about the rules governing the 
organization’s processes, customer requirements, or the organization’s culture. 

They often validate models and assumptions and are members of implementation 
teams as trusted stakeholders providing change leadership. 

Executive Sponsors: Management and Leadership 

The role of executive leadership is critical to business process management. The 
executive leader(s) set the vision, tone, and pace of business process improvement. 
They determine the direction and strategy of business process management, 
focusing the enterprise on its larger objectives. They allocate resources and reward 
success. They may unify the various missions and groups throughout the enterprise, 
and appoint and empower process owners or other individuals playing key roles in 
the management of business processes. 

Executive leaders may even be process owners themselves, owning and 
institutionalizing the process of process management. They act as champions 
inspiring the enterprise to change, sometimes by creating a sense of urgency to 
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overcome skepticism and resistance. To do this they must communicate the case for 
process management and remove obstacles that may impede progress toward the 
goal. They are responsible for creating the environment for success, sometimes 
through influence and persuasion, other times by resolving conflict and removing 
roadblocks. 

IT Organization Roles 

There are a number of roles within Information Technology groups that may play an 
important part in business process management, including: solution architects, 
system analysts, BPMS configuration specialists, developers, database 
administrators, and others. These experts help define supporting technology 
solutions and may assist in defining new capabilities for business processes based 
on enabling technology. They assist in process transformation initiatives through 
the implementation of new technology, while ensuring that the company’s technical 
standards are enforced. 

Other Roles 

Process owners require the support of a team. Supporting roles may include: design, 
architecture, mapping, modeling, tool management, repository management, change 
management, and other critical skills. The ABPMP collaborated in a survey that 
identified over 100 titles and roles introduced by organizations undertaking 
business process management initiatives (see Figure 60). Different organizations 
may use different titles to describe various roles with similar or overlapping 
responsibilities. Often, a single individual provides the skill and leadership required 
for two or more of these roles. Several chapters in this Common Body of Knowledge 
provide additional discussion on some of these roles. 
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Table 2 -100 New BPM Job Titles 


V 200b BPM Group All Rights Reserved 


Rank 

Job 

Rank 

Job 

1 

Business Process Manager 

51 

Procoss 8 Quality Manager 

2 

Business Process Analyst 

52 

Process A Organisational Performance Advrso* 

3 

Busi nos* Process Consultant 

53 

Principal. Process and Pert Mgt 

4 

Business Process Architect 

54 

National Practice Leader - Business Process Optimization 

5 

Director Bus. ness Process Management 

55 

Mgr. Business Process Services 

6 

Business Process Lnginoor 

56 

Managor, Continuous Procoss Improvomont 

7 

Process Engineering Manage* 

57 

Manager. Business Process Analysis 

8 

Process <>*nec 

56 

Manager. BPM Business Programs 

9 

Business Process Officer 

59 

Manager, Adaptive Infiastructure BPM 

10 

BPM Proioct Loader 

60 

Managor Procoss Managomont Group 

11 

Process Design Manager 

61 

Manager Center of Excellence Process Management 

12 

Process Designer 

62 

Manager Business Process Engineering 

13 

Pnnciple Process Consultant 

63 

Manager Business Process Alignment 

14 

Business Process Team Leader 

6-1 

IT ProcesVCosl/Metrics Specialist 

IS 

VP, Procoss Management 

65 

If Procoss Development Analyst 

16 

Director. Business Process Improvement 

66 

IT Process Analyst 

17 

Enterprise Process Architect 

67 

IT Business Process Architect 

IB 

Business Procoss Specialist 

68 

IT Basod Businoss Procoss Roongmoonng 

19 

Business Process Improvement Manager 

69 

IS Process Consultant 

20 

Business Process Developer 

70 

Innovation A Process Manager 

21 

Process Improvement Consultant 

71 

Mead of Quality 8 Process. Information Services Dnnsion 

22 

Business Process IV Quality Matuigm 

72 

Head of Process Improvement 

23 

BPM Researcher 

73 

Head of Procoss Architecture 

24 

Business Process Administrator 

74 

Head of Procoss & Automation 

25 

VP. Process Engmeonrvg 

75 

Head of Business Process Management 

26 

VP. Business Process Consulting 

76 

Head Business Process and Analysis 

27 

Sales Process Change Manager 

77 

Group Managor - Process Managomont & Improvomont 

28 

Process Strategy Consultant 

76 

Global Supply Chain Planning Process Leader 

29 

Process Optimisation Manager 

79 

Executive Director for Business Piocess 

30 

Procoss Modollor 

80 

Lntorpnso Businoss Procoss Managor 

31 

Process Management Specialist 

81 

e-business Piocess Manager 

32 

Process Management Coordinator 

62 

Director, Businoss Process Technologies 

33 

Process Integration Lead 

83 

Director Process Development and Quality 

34 

Process Inprovement Specialist 

8*1 

Director Marketing BPM 

3S 

Process Improvement Officor 

85 

Diroctor IT 8 Procoss Managomont Europe 

36 

Process Improvement Manager 

86- 

D» rec tor Business Process Change 

37 

Process Improvement Engineer 

87 

Deliveiy Manager BPM Solutions 

38 

Procoss Lxocubvo 

88 

Businoss Procoss Quality Managor 

39 

Procoss Dovolopment Team 

89 

Businoss Procoss Outsourcing 

40 

Process Development Manager 

90 

Business Process Opti miration 

41 

Process Development Engineer 

91 

Business Process Marketing 

42 

Procoss Dovolopor>'Pro|oct Managor 

92 

Businoss Procoss Innovation Managor 

43 

Process Coordinator 

93 

Business Process Development Manager 

44 

Process Consultant 

94 

Business Procoss Designer - Project Manager 

45 

Process Assurance 

95 

Business Process Oosign Mgr 

46 

Process Assistant 

96 

Business Process Atliuiktlion Consultant 

47 

Process and Process Management Specialist 

97 

Business Process Arch / Projoct Managor 

48 

Process and Change Management 

96 

BPM Specialist 

49 

Process Analysis. Education and Communication 

99 

BPM PreSales 

50 

Process & Systoms Integration Architect Director 

100 

BPM Lxocutivo 


Figure 60. One hundred new BPM job titles 


8.4 Governing Bodies 

As organizations mature in the management of their business processes, issues arise 
regarding process integration, such as how various processes must join as a 
collective whole to ensure a single, coherent organization that consistently delivers 
value across all of the company's processes. The organization thus needs to identify 
new mechanisms for planning, budgeting, and allocating resources to ensure that its 
processes are properly resourced, integrated, and aligned with strategic objectives. 

Organizations must have a clear governance structure to provide leadership and 
clarify decision-rights to enable cross-functional and departmental process 
improvement or management programs to succeed. Often, the root of resistance to 
business process management initiatives, sometimes causing them to fail, is change 
in the organizational governance structure. Individuals who may have had a great 
deal of power and control over resources based upon organizational functions, 
product lines, or geographic boundaries may find that their performance measures, 


329 


Copyright ABPMP International 



Chapter 8. Process Organization 


authority, and span of control must change in order to successfully implement 
business process management. 

The reason for change is simple. Business process management provides an end-to- 
end perspective on how work is done. This end-to-end perspective crosses 
traditional organizational boundaries and requires that the mechanisms by which 
decisions are made and resources allocated must also be aligned with the end-to- 
end business process. Sound governance provides a structure of authority and a 
framework for collaboration. The structure and framework enable proper allocation 
of resources and efficient coordination of activity control throughout the 
organization. Traditional managers who are unable to adapt their thinking beyond 
their organizational silo to end-to-end business process management are likely to 
resist initiatives that potentially change their influence in the organization. 

8.4.1 Process Governance 

There is no single, standard, process governance structure widely in use. 
Organizational focus on process is still emerging and a variety of governance 
structures are in use and evolving. Issues such as organizational strategy, culture 
and process maturity, business process outsourcing, and even the nature of 
individual leaders can cause a significant deviation from any given governance 
framework. 

According to Forrester Research, "Business professionals hold the key to 21st 
century business transformation as process skills migrate out of IT departments and 
into business operation groups. Supply Chain is a perfect example where, depending 
on the industry, there are critical processes like Order to Cash, Manufacturing to 
Distribution and Request to Service [that] have explicit ownership along with the 
appropriate roles and skills to manage and improve process performance, which 
directly impacts the top and bottom lines of companies." 

Information Technology is an enabler in the Supply Chain example, as it is in many 
other process examples. The partnership between the business and IT is critical to 
the success of business transformation efforts. There have been many studies in the 
ERP arena that have looked at the importance of first designing business processes 
and implementing them prior to IT implementations. Panorama Consulting has 
published an ERP report every year for the last three years and has observed the 
same results across multiple industries. 

The 2010 ERP report (http://panorama-consulting.com/resource-center/2010-erp- 
report) mentions that more than 67.5% of ERP implementations fail to realize the 
business improvement benefits. According to the study, the best-in-class companies 
who realize the business benefits of ERP tend to have the following best practices: 

• Exquisite focus on the business processes, that is, identifying the primary, 
management, and support business processes, and then defining and 
designing them for optimal performance. Choosing the software to fit the 
process is the goal, yet most companies get too tied up in the technical 
capability of supporting software and forget about the business process. 


330 


Copyright ABPMP International 


Chapter 8. Process Organization 


• Focus on achieving a healthy ROI based on business performance and having 
a business case that addresses post-implementation performance 
measurement. 

• Strong commitment from senior business executives with CIO or IT 
alignment to a common set of goals. 

• Adequate change management and training for the new processes and 
systems. 
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Figure 61 (Source: http://panorama-consulting.com/resource- 
center/2010-erp-report 


8.4.2 Process Council 

Organizations undertaking the process journey should consider instituting a Process 
Council or Business Process Management Center of Excellence (BPMCOE) to address 
enterprise process management and performance issues. Research from both 
Forrester and Gartner stresses that successful companies have instituted Business 
Process Management Centers of Excellence or Process Councils to address 
enterprise-level process performance issues. "The EA View: BPM Has Become 
Mainstream," from Forrester Research (February 19, 2009), indicates that "...of the 
companies experiencing clear, measurable improvement due to BPM, 49% have a 
COE [0]f the companies that had no success with BPM, 4% have a COE." 

A Process Council (see Figure 62) may be made up of a combination of executive 
leaders, functional or departmental heads, and the process owners of the core cross- 
functional enterprise processes. Its mission may include the identification and 
resolution of any cross-process integration issues, conflicts between process and 
functional (or departmental) ownership, resource allocation, and the development 
and alignment of the organization's business objectives, goals, and strategy. 
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FftCilty MarUkgwnont. Me. 

Figure 62. Process Leadership 

What is important is that companies ensure the Process Council structure is set up 
for efficiency and effectiveness in execution, so as not to entangle themselves in a 
process council bureaucracy. 

8.4.3 BPM Office or BPM Center of Excellence 

Some organizations, particularly in government, have created what is referred to as 
a Business Process Management Office (BPMO) or a BPM Center of Excellence 
(BPMCOE). Many BPMOs act in a manner similar to that of a project management 
office, identifying, consolidating and reporting status on various process 
improvement projects across the enterprise. BPMCOE charters include setting 
standards, providing common tools and methods, training and education on 
business process management principles and practices, providing governance on 
overall process design, and integrating business processes at the enterprise level. 
BPMOs and BPMCOEs play an integral role in prioritizing and allocating scarce 
resources to business process improvement efforts, as well as tracking and 
reporting process performance metrics to the respective process owners and 
executive management. 
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8.4.4 Setting Up a Business Process Management Center of Process 

A white paper developed by Sawion provides a nine-step methodology for setting 
up a Business Process Management Center of Excellence. This methodology is 
summarized in Table 27. 


Setting Up a Business Process Management Center of 

Excellence 

# 

Step 

1 

Attain executive sponsorship 

2 

Define goals and Success criteria 

3 

Define governance structure 

4 

Establish a BPM architecture 

5 

Set up BPM library and repository 

6 

Establish change management practice 

7 

Take process inventory 

8 

Prioritize process selection based on strategic 
objectives 

9 

Start executing BPM projects 

Table 27. Setting up a BPM Center of Excellence 


Government Organizations and BPMOs 

In government, many BPMOs have a role in enterprise architecture efforts as 
mandated by the Office of Management and Budget (OMB). The 0MB Federal 
Enterprise Architecture Framework (FEAF) requires agencies to maintain models of 
their key business processes and relate them to other architectural models such as 
business reference, technology, and performance models. BPMOs are responsible 
for maintaining the repository of process models, identifying opportunities for 
improvement, and working with various stakeholders in the development of 
business cases for process improvement and transformation efforts. 

Functional Centers of Excellence 

As businesses mature in implementing process management, assigning 
accountability for the management of core business processes, and developing 
mechanisms to integrate and align these processes, they may discover the nature of 
how work is performed and improves in the organization. Rather than command 
and control of the performance of individual tasks, process owners find that they 
need to be supported by cross-functional teams who are also focused on the 
performance of the overall process. Instead of command and control oversight, 
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these teams may work relatively independently, with guidance and support from 
management. 



Figure 63. The need for cross-functional process collaboration 


Companies encounter a need for change in the required skills and culture of their 
organization as they gain experience in process management. They need to maintain 
and integrate new skills and professional expertise across all business processes. 
Specialized skills may have previously resided in a functional group of the 
enterprise. Best practices groups, sometimes called centers of excellence, provide 
knowledge, standards, best practices, training, and education. They are responsible 
for ensuring the proper resources with proper skills are placed and allocated 
properly throughout the company's business processes (see Figure 63). 6 

Centers of Excellence may be virtual organizations (often known as a Community of 
Interest, or COIN). They may simply comprise an email distribution list to connect 
all engineers, or they may be robust, institutionalized groups with large training 
facilities. Many centers of excellence are organized around a particular skill or 
profession, such as sales, marketing, finance, and information technology. Coaches 


6 Concept derived from Dr. Michael Hammer’s 1997 book Beyond Reengineering - How the 
PROCESS CENTERED ORGANIZATION IS CHANGING OUR WORK AND OUR LIVES. Dr. Hammer discusses 
several case studies relating to the evolution of the process-centered enterprise, including the 
introduction of centers of excellence. 
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may be assigned to business processes from the Centers of Excellence, with a 
responsibility for supporting and developing members in order to ensure that the 
caliber of localized skills is maintained and enhanced. Centers of Excellence offer 
training and education programs as well as professional networking for sharing 
experiences. Some organizations use Centers of Excellence as an entree for people 
into the organization; i.e., they are hired by the center and deployed from the 
centers to process teams. 

8.5 A Summary Discussion 

Every enterprise is unique, with its own unique culture, values, incentive systems, 
business processes, and structure. Today many companies are still structured 
around a functional hierarchy, with little or no accountability for their end-to-end 
business processes, which deliver customer value across functional silos. However, 
companies that have made the transition to Process Councils and Business Process 
Management Centers of Excellence seem to have had much more success than those 
that have not made the leap into BPM process governing structures. 

As the power and benefit of managing business process becomes more prevalent, 
organizational focus and structure are likely to progress to include a process 
dimension. This development may lead to significant change in how work is 
performed and managed. It will involve new roles and responsibilities, performance 
measures, and compensation plans. Businesses have found that the notion of 
process ownership is critical to the successful management of their core business 
processes. 

There is no single structure, set of tiles, roles, or culture that is clearly emerging. 
However, many companies appear to be adapting to business process management 
and have many attributes in common, in terms of their orientation to process, 
setting up a governing body (either stand-alone or as a council), and developing the 
skill sets to improve process performance. What is clear is that Process 
Organizations are taking shape and developing, and best practices are emerging that 
are clearly setting apart those who have embedded process within their 
organizations and those who have not. 

8.6 Key Concepts 


Process Organization — Key Concepts 

Fostering a process 
culture 

An enterprise fosters a process culture when the 
business’ processes are known, agreed upon, 
communicated, and visible to all employees. 
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Process Organization — Key Concepts 

Characteristics of the 

process-maturing 

enterprise 

As an enterprise matures in managing its business 
processes, its organizational structure will naturally 
tend toward change, which comprehends a process 
dimension. Management of work from a downward 
managerial command-and-control approach adapts to 
include a horizontal dimension reflective of end-to-end 
processes, driving accountability to the customer for 
delivery of value across functions. 

Process owner 

An individual or group is assigned the role of process 
owner for a complete end-to-end business process. The 
process owner has an ongoing responsibility and 
accountability for the successful design, development, 
execution and ongoing performance of this process. 

Process supporting 
roles 

Successful process management within an enterprise 
will involve numerous roles in addition to process 
owner. Some individuals will have responsibility for 
more than one role. The more common roles include 

• Process manager, 

• Process analyst, 

• Process designer, 

• Process architect, 

• Business analyst, 

• Subject matter expert, and 

• Executive management and leadership. 

Process governing 
body 

To enable cross-functional and departmental process 
improvement or management programs to succeed, 
organizations set up a distinct governing body to 
provide leadership and clarify decision rights 

Governance structure 
standards 

While there are many governance structures (governing 
bodies) proposed and implemented, there is no single 
standard for creating an organizational focus on process. 
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Process Organization — Key Concepts 

Process Council 

A Process Council, made up of executive leaders, 
functional or department heads, and process owners, is 
one common approach to process governance. The 
Process Council 

• Ensures alignment of business processes with 
enterprise strategies, goals and objectives, 

• May have responsibility to identify and resolve 
cross-process integration issues, conflicts 
between process and functional ownership 

• May have responsibility for the allocation of 
business process management resources. 

Additional process 
governing bodies 

Other organizational approaches to process 
management include establishing a 

• Business Process Management Office (BPMO), 

• Business Process Management Center of 
Excellence (BPMCOE), or 

• Functional Center of Excellence (often known as 
a Community of Interest, or COIN). 

Setting up a Business 
Process Management 
Center of Excellence 

• Attain executive sponsorship 

• Define goals and Success criteria 

• Define governance structure 

• Establish a BPM architecture 

• Set up BPM library and repository 

• Establish change management practice 

• Take process inventory 

• Prioritize process selection based on strategic 
objectives 

• Start executing BPM projects 

Business Process 

Management 

Professional 

Business Process Management Professionals must 
understand the myriad of potential organizational 
changes that may be brought about through increasing 
process maturity, so that they can guide the enterprise 
through the transition. 
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Foreword by Peter Fingar, Business Strategy, BPM, and Globalization 
Advisor at PeterFingar.com 

Back to the Future of Enterprise BPM. Process is nothing new, but the capability to 
manage end-to-end processes has progressed through three waves over the past 
several decades. 

The First Wave. In the first wave of business process management, which began in 
the 1920s and was dominated by Fredrick Taylor’s theory of management, 
processes were implicit in work practices and not automated. After World War II, 
however, applying science to process became front-and-center as W. Edwards 
Deming and Joseph Juran taught the Japanese about the power of quality 
management. Their work and that of others triggered a wave of total quality 
management (TQM), spurred on by the publications of Deming and Juran in 1982, as 
shown below. The emphasis was not so much on the design of new processes, but on 
statistical measurements as a means of improving work practices and quality. 
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The Second Wave. Then a decade later, the 1992 blockbuster book Reengineering 
the Corporation hit corporate board rooms. In this second wave of business 
process management, processes were manually reengineered and, through a one- 
time activity, cast in concrete in the bowels of today’s automated Enterprise 
Resource Planning (ERP) and other packaged systems. Although "downsizing" is the 
moniker most remembered from Hammer and Champy’s Business Process 
Reengineering (BPR), it was technological enablement that allowed companies to 
tear down functional silos and reengineer end-to-end business processes that 
spanned individual functional departments (silos). Historically, ERP solutions had 
all the flexibility of wet concrete before they were installed and all the flexibility of 
dry concrete after installation. Even with document-centered workflow added to 
ERP, such systems only took up discrete roles as participants in processes; rarely 
did they provide business management control over the processes. Those that did, 
only did so for subprocesses and were generally limited in their capability. 
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The Third Wave. In the Third Wave of BPM, the business process was freed from its 
concrete castings and made the central focus and basic building block of automation 
and business systems. Processes became first-class citizens in the world of 
automation. Change was the primary design goal because, in the world of business 
process management, the ability to change is far more prized than the ability to 
create in the first place. It is through agile business process management that end- 
to-end processes can be monitored, continuously improved and optimized. 

Feedback of results, agility, and adaptability are the bywords of the third wave. The 
question is, however, how can such noble goals be attained? And the answer came in 
the form of a Business Process Management System (BPMS) that, unlike an ERP 
system with data and applications at its core, places the abstract data-type of 
process at the core. In lay terms, the BPMS places the notion of process center stage 
in the world of technological enablement for business change. 

Happy Anniversary and the Next Decade. As the coauthor of The Third Wave, it’s 
hard to believe that 2012 is its tenth anniversary (I suppose the title of grandpa 
does indeed apply). But instead of celebrating the Tin Anniversary, it’s also 
somewhat disheartening that the "M" in BPM has often been ignored. As process 
luminary Andrew Spanyi famously asked, "How has BPM actually changed the 
behavior of leadership?" Such questions go straight to the heart of true business 
transformation. In some cases the BPMS has been used for little more than a newer 
version of enterprise application integration (EAI) or traditional workflow. While 
such approaches can improve back-office efficiencies, where’s the competitive- 
advantage beef? As we'll explore in this chapter, the word "enterprise" has to be 
appended to the term BPM. For that to have meaning, companies must cross over 
from "organization management" of people to process management that supersedes 
organization management and spans multiple organizations. Politics and inertia are 
the high-barrier obstacles, and this chapter explores how to navigate these obstacles 
to harness the true value of process management, strategic BPM. 

Okay, your organization has made the big leap to Enterprise BPM. But that doesn’t 
signal the beginning of the end of your BPM journey; it signals the end of the 
beginning of a much more challenging journey. Now what? 

In today's world of globalization and extreme competition, leadership (the "M” in 
BPM) must extend not just across the enterprise, but also across the entire value 
chain! 

Companies don’t work alone, and, on average, over 20 companies make up today’s 
value chains — sometimes hundreds. This is especially important to recognize, as no 
one company "owns" the overall value chain. In Management Challenges of the 
21st Century, the late Peter Drucker elaborates, "The legal entity, the company, is a 
reality for shareholders, for creditors, for employees and for tax collectors. But 
economically, it is fiction. What matters in the marketplace is the economic reality, 
the costs of the entire process, regardless of who owns what. Again and again in 
business history, an unknown company has come from nowhere and in a few short 
years has overtaken the established leaders without apparently even breathing 
hard. The explanation always given is superior strategy, superior technology, 
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superior marketing or lean manufacturing, but in every single case, the newcomer 
also enjoys a tremendous cost advantage, usually about 30 percent. The reason is 
always the same: the new company knows and manages the costs of the entire 
economic [value] chain rather than its costs alone.” 

The challenge ahead is to take the huge leap from Enterprise BPM to Value Chain 
BPM, and cloud computing provides the technological enablement for that leap. 
Cloud computing allows a company to collaborate in new ways with its trading 
partners, and process collaboration across the value chain is the key to gaining 
competitive advantage. As explained in the 2012 book, Business Innovation in the 
Cloud, by establishing shared workspaces powered by a shared BPMS in 
"Community Clouds,” employees from multiple companies can work together as a 
"virtual enterprise network" and function as though they were a single company. 
They all participate in the same value-delivery system, sharing computing, 
communication, information and BPM resources. No, this is not some 800-pound 
gorilla dominating the value chain, using its might to squeeze suppliers. It’s about 
Open Leadership, Collective Leadership, and Collaborative Key Performance 
Indicators (KPIs) that foster trust (for real data sharing) and incentivize all 
participants in the value-delivery ecosystem in the Cloud. 

By taking the BPMS as the technological enabler into the Cloud, companies and their 
suppliers and customers can build and manage dynamic Business Operations 
Platforms (BOPs) or Business Networks (Business "Operating Systems," if you will). 
As with Enterprise BPM, success with Value Chain BPM won’t magically happen 
because of technology-enablement in the Cloud; it will be the "M" in BPM that once 
again counts. Leadership is all in the new world of extreme total global competition. 
The lesson is short: innovate or die; and the cornerstone of business innovation is 
management innovation. 
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9.0 Introduction 

Fundamentally, organization management is about managing people and how they 
do work. It is concerned about efficiency. Process management is about managing 
how all the work needed to deliver an end product or service (regardless of who 
does it or where) fits together and is performed — for quality, timing and cost 
management. 

Enterprise Process Management represents a new way to view a business 
operation — one that does not fit a traditional organization structure. This view 
spans an entire process and includes all the work that is performed to deliver the 
process’ product or service, regardless of what business units or locations may be 
involved. This view begins at a higher level than the level in the organization that 
actually performs work and then breaks down into subprocesses, which may be 
performed by one or more business units, and then to activities and their workflow 
within business units. 

This higher-level perspective is critical in controlling the impact and thus the benefit 
of changes in the business operation. Change is now viewed from both its impact on 
the individual business unit that is making the change and from its impact on the 
activities upstream (how they will need to change to provide the material, 
documents, information etc., that the changed business activity requires) and 
downstream (how consumers of whatever the changed business unit produces will 
be required to modify their work, in order to consume what is now going to be 
produced). This provides a very different view of cost, impact, and benefit that is not 
available in the traditional organizational view of the business. 

This broader view of the business management involves all aspects of the process — 
its cost, its problems, its systems, its quality, and its performance. This is 
independent of where the work is done — internal or external, in the same location 
or other geographical locations, in subsidiaries or outsourced. It views all groups as 
suppliers of components of the work and the process as the integrator of the 
components. This allows management to have a different view of performance, cost, 
and quality. In this view, management can evolve meaningful KPIs for each of the 
components in the process and measure performance against them — allowing all 
parts of the business to essentially compete, based on price, service, quality, and on- 
time delivery, with other internal and external suppliers. 

Of course, if all work remains internal within the company, this view allows 
management to benchmark each component in the process as the baseline for a 
quality improvement program and to constantly promote quality improvement, 
customer service improvement, and cost reduction. 

This gives management a level of control that has not been possible in the past. This 
also allows Senior Management to gain better visibility into the operation and the 
way product or services are built, delivered, and invoiced. It ties everything together 
from a product perspective and offers a different way to look at cost — as it relates to 
the process and its components. It also allows them to identify weaknesses in the 


344 


Copyright ABPMP International 


Chapter 9. Enterprise Process Management 


way product is built and the way the product is managed — from sales through 
delivery. 

9.1 Transitioning to Enterprise Process Management 

Most change today is focused on small improvement or problem-resolution projects. 
A few projects are actually broad enough to be transformational and deliver 
fundamental changes in the way the business is viewed and the way work is done. 
But more often, changes to rules, operations, policies, and procedures are made 
every day; over time they become institutionalized as unwritten (and unapproved) 
law in the way the business operation works. Together, these changes cause 
constant disruption, impair productivity, and build a layer of unintended regulations 
around real work. 

While this unintended overhead causes harm, the biggest problem caused by today’s 
narrowly-focused change is the ripple of the changes as their impact accumulates, 
introducing constant problems into upstream and downstream business operations. 
While most small changes have a minimal impact on other parts of the operation, 
over time, these small changes combine to have a serious impact, disrupting 
operations and degrading both quality and performance. 

This creeping disruption is caused by the narrow perspective required by 
management under the current organizational view and the limits it imposes when 
looking at change and its impact. Removing this limitation is among the key reasons 
to move to a process perspective and create a process management approach to 
controlling change and improving both quality and performance. 

9.1.1 Building the Business Case for Moving to a Process Centric Model 

"If it is worth doing, it is worth doing right"; but as they say in the medical 
profession, the first rule is "do no harm." After that, all that’s left is improvement. 

But how do you know that what you think is right will do no harm to others? That is 
the infamous ripple effect that both IT and business operations struggle with every 
day. The root cause of this problem has been an inability to predict impact and 
mitigate the potentially negative side of it. 

The underlying reason for this problem’s existence is that change has usually been 
viewed from an organization perspective. While this has been the only perspective 
available to most managers, it is not a real view of how business actually works. 

Each business unit performs work that is basically the same each day. What is done 
is based on what the business unit staff receive from outside the business or from 
another business unit. They then take some action and pass the work on to another 
business unit. But, concepts of 'change' seldom comprised or considered what is 
happening outside any business unit. The reason why is based on the organizational 
view of the company. Managers are judged on how their business unit performs and 
how close they come to meeting their business unit goals. In this view, there is 
generally no consideration for the impact of a change on others, and this has limited 
management’s ability to look beyond the usual organizational silos. To be fair, 
however, until recently there has been not alternative to the organization view. 
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But this is changing as companies like UPS and Sloan Valve move to provide a 
process perspective that complements the normal organizational perspective. 

In today's business environment, it is critical to optimize the result of any change 
expenditure. Companies are not spending money on high-risk improvement 
projects. But, given the problems associated with the narrow organizational view 
that management has had to deal with, the question becomes, "how can 
management be certain that every dollar spent on improvement actually improves 
the immediate operation while at least causing no harm in other parts of the 
company?” At ABPMP, we believe a large part of the answer is to provide a view of 
the entire processes in a company or to at least track work and build high-level 
process models in the areas that will be changed. 

While this may seem like a significant effort, it is actually manageable given today’s 
BPMS technology (see chapter 10). In addition, it is not necessary to identify or 
define in detail all the processes in a company for a Project Manager or team to 
begin to integrate a process perspective into their projects. High-level processes and 
the way they interweave can be quickly identified and defined by working backward 
from product delivery or service delivery. But this requires a shift from congenital 
thinking, or the belief that you must be 100% right and complete in anything that is 
done. 

BPM is all about iteration and evolution to optimization. You are not expected to 
spend long periods in the analysis and redesign to try to get to the 100% level. You 
are expected to move quickly and come close to right, and then find holes and errors 
and iterate again. In this way, everything evolves and change happens quickly, with 
the serious problems being corrected first. This gives the greatest benefit early in 
the project and changes the benefit curve. 

When applied to process, the company can move quickly and identify a first cut at 
high-level processes and the way they interact, and then iterate and refine the 
models. This provides a framework for the evolution of detail through projects in 
different business units, which fill in the detail. 

For a project to build this view, the Project Team will need to work their way 
upstream in the activities that feed the part of the business that will be changed. 
Then they need to work downstream, following the consumption of the deliverables 
of the work that will be changed. This tracking must go all the way to the beginning 
and the end points. 

What this provides is a way to check changes against impact outside the business 
unit. 

This check will show how any change can cause disruption downstream and 
additional requirements of business units upstream. With this new information, the 
team can take a broader view and avoid solutions that cause harm to others, which 
may result in serious business disruption. 

In addition, moving to a process-level project, the company can look at quality and 
cost in a very different way. While each business unit can impact quality and must 
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thus control it, overall quality requires a process perspective to manage the "build" 
of quality problems and eliminate them. 

With a process perspective, the Project Team will be able to collaborate with other 
potentially impacted business groups to avoid change-related problems and 
implement a more comprehensive type of performance measurement and quality 
monitoring — saving time, money, disruption, and avoiding sudden quality problems. 
It will be able to look at the root causes of problems outside the business unit, often 
for the first time. 

9.1.2 Getting started— the importance of leadership, BPM leadership plan 

Process Management cannot be viewed in terms of a traditional organization 
structure. It is separate and it doesn’t align to the organization. In reality, process is 
cross-organizational. It winds through multiple organizations, with each adding 
some component or part of the final product or service. The process doesn’t need to 
be limited to any one location or even to any one company — as in outsourcing or the 
purchase of parts, sub-assemblies, or services that join to produce the product. 

Because it is totally independent from organization management, process 
management will require a separate view of the operation and a separate set of 
process managers. These managers should be responsible for the overall quality and 
efficiency of one or more processes, depending on their size and complexity. Also, 
because this is separate from the normal organization structure, the process 
managers should report to a separate executive. This will allow them to remain 
independent of the normal operational concerns that affect the organization 
structure. 

These managers must have a unique set of objectives that they are measured 
against. Their concern is the process and its improvement in terms of recognition 
from business-unit managers that they are part of a larger operation involving 
collaboration among the business unit managers, overall cost, timing, quality- 
improvement for the process, and customer-satisfaction improvement. Of course, to 
do this, the company will need to define processes, and start to measure the things 
that process managers will be responsible for. But using BPMS technology support, 
this information can be obtained and the process management activity can be 
controlled. 

However, to be effective, the process managers must have the authority to work 
with all levels of business unit managers, and when collaboration breaks down, to 
access senior executive management for arbitration. 

9.1.3 Where Process and Organization Come Together 

As noted throughout the CBOK, process can be broken into multiple parts focused 
on different levels — for discussion, let’s call them Business Functions, subprocesses, 
activities with workflow, tasks, work steps. The number of levels and the names of 
those levels will change by company or department within a company. There are no 
standards in the industry. But the number of levels in your definition of process and 
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the names you call them are not what is important. What is important is that they 
formally exist. 

Using this version of levels and names, we will say that process intersects with 
organization at the activity (workflow) level, where work is now broken apart and 
assigned to business units to be executed. This is the point where process 
management and organization management, and a relation between their respective 
managers, come together. 

This link forms a type of map of process execution and moves it from a conceptual 
entity to a physical entity: the work is no longer just an idea — it is tangible. The 
process manager must now form a separate management group of the business 
managers whose organizations perform the work that delivers the process’s 
product or service. This is a committee that must be responsible for improvement in 
the process and in the individual business units. They must look at proposed 
changes in all business units and make certain that solutions do not negatively 
impact their individual business units or the process. Creating this committee must 
be part of the Process Manager’s formal responsibility. 

However, because a process view is very different from what most managers are 
familiar with, it is necessary for the Process Manager to provide information on 
what is involved, how it all fits together and how it is managed. This, frankly, cannot 
be provided through the use of low-level draw tools. Organizing this information 
and controlling it can best be supported through a BPMS. This will allow the 
company to have both end-to-end process views of the business and detailed views 
within business units. It will also allow all components, sub-assemblies, etc., to be 
identified and where they are created, used, modified, joined into larger sub- 
assemblies, etc., to be tracked. In addition, problems can be shown, process and 
workflow monitored and reported against, and the main rules that drive the quality 
process and timing to be known and adjusted to optimize the operation. 

But, most importantly, a BPMS provides a common base for the Process 
Management committee to prioritize change projects, review change, look at 
potential impact using simulation modeling, and monitor the process as it moves 
from business unit to business unit. 

Without this support, the Process Management committee can certainly be effective, 
but the amount of work will be significantly increased, and reporting to the group 
will be delayed. 

9.1.4 Things to consider: Process Frameworks & Industry Reference 
Models 

Fundamental to Business Process Management in an organization is the Enterprise 
Process Model. Most organizations will benefit greatly from utilizing a Process or 
industry reference model as a starting point for the classification of processes. 
Process frameworks can be 
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• Generally applicable across different types of companies or organizations 
(APQC Process Classification Model, Value Chain Operational Reference 
[VRM]) Model) 

• Specific to an industry (Supply Chain Operations Reference Model) 

• Specific to a process area (Information Technology Infrastructure Library), 
or 

• Specific to technology (SAP). 

As outlined above, there are numerous reference models with applicability to all 
organizations, specific industries or even specific process areas or technologies, and 
combinations of all four. The APQC PCF and VRM can be widely used to support a 
number of organizations. The SCOR model is more specifically tailored to supply- 
chain organizations. At this same level, there are also numerous industry-related 
models. APQC has several variations for specific industries, such as pharmaceuticals. 
There are also more general architectures that include process views at an industry 
level: for example, eTOM is an architecture used by telecommunication companies. 
Some process areas can have specific models: ITIL describes the common processes 
to support an organization’s IT operations. There are even definitions of processes 
used to support technology, typically large-scale ERP implementations. SAP uses a 
specific process structure to support the blueprint of processes. 

Process and Industry models typically serve as a starting point for an organization 
to base its process design and are not meant to be an exhaustive representation of 
an enterprise. Depending on the organization, practitioners may leverage different 
components of varying models to create a structure that best incorporates the 
structure of an enterprise. Reference models can be useful in identifying a general 
taxonomy and ensuring that all aspects of process are thought of as part of the EPM 
development process. 

Process and Industry Reference Models can also be useful in tying in other common 
components of an overall business or technical architecture. By providing a common 
taxonomy or language to understand enterprise processes, organizations can better 
compare or leverage shared assets. An example of this is benchmarking. Common 
comparison of processes allows companies within an industry- or cross-industry to 
compare benchmarking data. Some reference models also include more technical 
aspects related to data or services model where the processes are the common 
framework for managing the content. Common understanding of processes across 
organizations and industries will become even more important over time to further 
support ERP development, commoditization of processes or technologies, and 
ultimately business process outsourcing. 

The purpose of this document is to outline the common types and uses of process 
frameworks; it is not an exhaustive list of all valuable methodologies. To serve as an 
example, we will provide further explanation of some of the more commonly used 
reference models below. 
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9. 1.4.1 APQC Process Classification Framework 
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Figure 64. APQC Process Classification Framework 

APQC is an international benchmarking clearinghouse that has collaborated with 80 
organizations in developing a framework for process evaluation. The APQC Process 
Classification Framework (PCF) can be used by many organizations as the starting 
point for an Enterprise Process Model. The APQC’s Process Classification 
Framework is meant to serve as a high-level, industry-neutral enterprise model that 
allows organizations to see their activities from a cross-industry process viewpoint. 
Originally created in 1992 by APQC and a group of members, the framework has 
been in use by many organizations on a worldwide basis. The APQC has indicated 
that the PCF is supported by the Open Standards Benchmarking Collaborative 
(OSBC) database and is an open standard. The APQC plans that the PCF will 
continuously be enhanced as the OSBC database further develops definitions, 
processes, and measures related to process improvement. The PCF is available for 
organizations of all industries and sizes at no charge by visiting 
http:/ /www.apqc.org. 
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The Process Classification Framework (PCF) set of tools provides a beginning for 
discerning core, support, and management processes common between and across 
industries such as manufacturing and service, health care, government, and 
education, to mention only a few. The PCF represents a series of interrelated 
processes that are considered to be business-critical. It can be used "to enable 
organizations to understand their inner workings from a horizontal process 
viewpoint, rather than a vertical functional viewpoint". 

The PCF consists of four phases: Prepare, Plan, Implement, and Transition. Prepare 
is a strategic phase. It is a comprehensive assessment that focuses on the core 
processes. During this phase, a business case is identified with opportunities and 
determines the expected business results. In the Plan phase, a time-phased 
approach to implement the changes identified during the assessment is developed. 
During this phase the process analyst and the analysis team refines, redesigns, or 
reengineers core business processes. In the Implement phase the changes are 
implemented. The Transition phase is both tactical and strategic. 

Tactically, employee teams develop process operating procedures and oversee the 
transition to the new process. Strategically, the organization will repeat the model 
with other processes, based on their business needs and priorities. 

9. 1.4.2 Value Chain Operational Reference (VRM) Model 

An additional model worthy of consideration is the Value Chain Operational 
Reference (VRM) Model. VRM attempts to integrate the three domains of a Value 
Chain: product, operations, and customer. 

The model has 3 levels of detail under one framework. The highest level is called 
Level 1, and the Level 1 processes of VRM are: Plan — Govern — Execute. In Level 2, 
as the figure below shows, the Level 1 process category 'Execute' is decomposed to 
the components of Market-Research-Develop-Acquire-Build-Sell-Fulfill-Support 
process categories. Level 3, which is not considered here, provides a more complete 
framework for understanding and control of the extended Value Chain. 

The VRM model supports the key issues and the meshing of processes within and 
between the units of chains (networks) for the benefit of Planning, Governing and 
Execution (information, financial, physical flows) with the objective of increasing 
performance of the total chain and supporting its continuous evolution. The Value 
Chain Group describes VRM as a model that provides "a common terminology and 
standard process descriptions to order and understand the activities that make up 
the value chain." 

Enterprises applying the model are provided with a framework to achieve their 
goals of both horizontal and vertical collaboration. The VRM model uses a common 
language while at the same time creating a foundation for successful Service 
Oriented Architecture. The VRM framework organizes processes through five levels 
representing the various layers of the organization. As the processes work their way 
from the bottom (actions) through the top to the strategic processes, they become 
more complex and closer to realization of the strategic goals. 
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Strategic processes are the top-level processes in the value chain. These are the 
processes specifically designed around customer needs and the business strategy. 
Decomposed from strategic processes, tactical processes outline how the goals of 
the strategic processes will be met. Tactical processes are derived from operational 
processes, which are where the work gets done. Activities are groups of actions that 
make up the operational processes. Actions are the last group of processes and 
represent individual items of work that cannot be broken down further. 

These processes are further governed by three macro processes that control the 
enterprise: Govern, Plan and Execute. 

9. 1.4.3 The Supply Chain Operations Reference Model (SCOR) 

The SCOR Model represents a framework that offers a means of facilitating the 
identification of process models for nearly any and all types of enterprises. This is a 
holistic end-to-end process inclusive of the supply chain ecosystem. Such a 
framework is valuable for enhancing enterprise and stakeholder (internal and 
external) communication for building and sustaining process-centricity into the 
enterprise. 

The Supply Chain Operations Reference-model (SCOR) has been developed and 
endorsed by the Supply-Chain Council (SCC), an independent not-for-profit 
corporation, as the cross-industry standard for supply-chain management. Initially 
this consortium included 69 voluntary member companies interested in advancing 
state-of-the-art supply-chain management systems and practices. It has since 
expanded its reach to healthcare, government, education, and many other service- 
based enterprises. 

9.2 Current state: Assessing Process Maturity 

Assessing an organization’s process maturity is an integral part of understanding 
where the organization is today and where it aspires to go in its overall process 
journey. There are numerous process maturity models that are used by a number of 
practitioners or vendors. They can range from the basic five-point scale to a multi- 
dimensional prescriptive methodology. 

Process maturity assessments typically assess the ability of an enterprise to support 
Business Process Management — they focus on the enterprise’s level of maturity 
with respect to BPM capabilities. At the same time, maturity assessments can gauge 
the capability of enterprise processes to deliver business results. In some cases, a 
process maturity assessment will capture both. Organizations may choose multiple 
maturity assessments over time and for different purposes. 

Process maturity assessments can be useful for establishing a baseline of existing 
capabilities and to align the organization on the current state. Assessments are also 
useful in identifying and addressing any gaps. The gap assessment can thus be 
prescriptive and assist an organization in creating actionable plans or an overall 
roadmap for Business Process Management, which will be discussed further in this 
section. 
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At the time of this publication, over thirty different process maturity assessments 
were identified from numerous consulting, analyst and technology vendors. This list 
continues to grow. The purpose of this document is not to identify all of the 
methodologies in the marketplace but rather illustrate the importance of conducting 
an assessment to establish a baseline and provide actionable guidance to achieve 
greater maturity. Practitioners must decide on the right model for their 
organization, depending on the overall strategy of Business Process Management. 

To illustrate, we will review two common maturity assessments going from the 
basic to the more complex. 

9.2.1 Capability Maturity Model Integration (CMMI) 

The Capability Maturity Model Integration (CMMI) is a process-maturity approach 
that can be used for a process, project, or an enterprise. CMMI is a registered patent 
by Carnegie Mellon University. The five-scale classification is typically less 
prescriptive than other methodologies but can be used as a general discussion guide 
in evaluating a specific process area or enterprise maturity. 


Characteristics of the Maturity levels 
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Figure 65. Maturity Levels 
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9.2.2 Process Enterprise Maturity Model (PEMM) 

The Process Enterprise Maturity Model (PEMM) was developed by Michael Hammer 
and summarized in "The Process Audit" (Harvard Business Review, April 2007). The 
PEMM is meant as a tool to help organizations plan and manage their transitions to 
process and consists of one framework for assessing the maturity of any particular 
business process and another for assessing the maturity of an enterprise as a whole. 
Hammer classifies these two components as two separate dimensions: 

Enterprise Capabilities — foundational requirements across the enterprise to 
enable successful process transformation within an enterprises specific processes 

Process Enablers — maturity of individual processes to drive process 
transformation within a business area. 

The Enterprise Capabilities include the following components: leadership, culture, 
expertise, and governance (see Figure 66). The Process Enablers include design, 
metrics, performers, owner and infrastructure. Hammer provides a four-point scale 
for each of these dimensions to assess and manage overall maturity. 



Enterprise Capabilities 



Process 

Enabler 

Process 

Enabler 

Process 

Enabler 

Process 

Enabler 

Process 

Enabler 


1 1 

U_J 

L_J 

L_J 



Figure 66. Enterprise Capabilities 


9.3 Process Enablement 

Core to enterprise process management are capabilities to support the overall 
enterprise in developing process capabilities. Essential to conducting enterprise- 
wide Business Process Management is an overall strategy to enable the 
organization. The enablement strategy should be described in detail and given as 
much attention as the processes themselves. In many organizations, an overall 
change management construct should be employed to ensure proper adoption by 
the organization. Although outside of the scope of this document, it is recommended 
that practitioners familiarize themselves with the basic principles of change 
management and incorporate them into the overall process program. In addition to 
change management, an overall structure for project and program management 
should also be incorporated. The enablement activities should be specifically 
defined within the overall roadmap, as discussed later in this section. For 
illustration, we will cover several important enabling concepts. 
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9.3.1 Training and Education 

Many aspects of business process management will require enterprise training and 
education to address numerous capability gaps in the overall maturity. To ensure 
that the concepts of business process management are adequately covered, 
practitioners should consider developing a detailed training and education plan. The 
education plan can be comprised of a stakeholder assessment, a listing of 
curriculum and delivery mediums, an education matrix, and an approach to content 
development and ongoing training development. Many large organizations have a 
dedicated training department that can assist in development. 

The stakeholder assessment should be aligned to the overall maturity assessment or 
defined BPM strategy for the enterprise. It should include the various stakeholders 
for BPM, specific requirements tied to process strategy, specific roles, and the type 
of information that is required. 

From the overall stakeholder assessment, the curriculum and delivery mediums can 
be drafted to best serve the needs of the stakeholders. This listing of courses can 
vary greatly depending on the overall level of maturity of various stakeholders and 
the strategy of the overall process program: courses can range from specific training 
on BPM technologies to what it means to be a process owner. Multiple delivery 
mediums — such as eLearning, Podcasts, classroom, and web training — should be 
considered, based on the type of training and the overall audience. 

An education matrix should be developed to tie stakeholders and specific learning 
objectives to the various training programs and mediums. A plan will also need to be 
developed on how to create this content and manage on an on-going basis. This 
should be included as part of the overall enabling roadmap (discussed below). 

9.3.2 Marketing and Communications 

In many enterprise projects and initiatives, this enabling capability would typically 
be called communications and focus primarily on providing process 
communications to the enterprise. However, given the strategic importance of 
business process programs and the organizational headwinds they face, the overall 
communication of Business Process Management to the enterprise should be given 
the treatment of a marketing campaign. Because of its scope, this document does not 
delve into the various aspects of marketing; however, it is important to note that 
practitioners should develop a plan to this level of detail that includes an overall 
strategy and targeted campaigns. Aspects of social media should also be considered 
to reach broader audiences. 

9.3.3 Process Scorecards 

Process scorecards can play an important role in the ongoing management of a 
process to ensure the overall operational objectives are met. Similarly, a scorecard 
should be considered as part of enabling enterprise process management. Metrics or 
Key Performance Indicators (KPIs) should be defined as part of the overall process 
program that aligns with specific objectives as defined by the process roadmap, 
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discussed later in this section. The scorecard should be used a mechanism to track 
enterprise enablers against overall goals. 

9.4 Process Governance 

While the Process Manager will have responsibility for the overall activity in the 
process, that will not take the place of the normal Business Unit Manager’s 
operational responsibility. The Process Manager will have a broader operational 
responsibility, but he or she will typically not have the authority to directly guide 
the Business Unit Managers. This makes for a difficult situation and it is the reason 
the Process Manager must have a way to deal with disagreement, recalcitrant 
Business Unit Managers, and often conflicting priorities and interests. 

A large part of this ability to deal with the problems is related to working with 
managers who must, by personal evaluation requirements from their own bosses, 
focus on their individual operations. It would be nice if people always played nicely 
with one another, but they don’t. This is reality. To mitigate this reality, it is 
necessary to implement a process governance structure with separate rules that 
control the interaction between the managers on the Process Management 
committee and way that priorities are set and performance is managed. 

These rules will be unique to each company and reflect the company’s culture and 
the way the process is performed. Consider an example in which parts are 
outsourced or replaced by purchasing sub-assemblies that were once built in-house. 
Control of the process and governance would change, and must be formally created, 
accepted and managed by the Process Manager. Without it, the committee would be 
chaotic and fail to deliver real process management. 

However, in all governance, care must be taken to find the right balance between 
control and flexibility. Too much flexibility entails ineffective control; with too much 
control, everything becomes a challenge. Finding the right balance will be a 
negotiation in all companies: no managers willingly give up their freedom to act or 
their authority to make change-decisions. That is why consensus on the rules that 
control governance is important. It is also why senior executives’ higher authority is 
critical — there will always be disagreements when authority is being taken away. 

In addition, a move to a process viewpoint will push managers into unfamiliar 
territory, especially when there are so many definitions of what a process is. This 
problem is manifest in the fact that, in many companies, a "process" is any group of 
tasks or, in some cases, a single task. In these companies, the concept of process 
management will be a struggle for many managers, and it will take time and 
possibly executive definition mandate and executive decree that the company or 
department is moving to include a process view as part of the way they will manage 
work and change. 

9.4.1 Role of Governance in the Process Organization 

Process governance is the mechanism for creating the rules and standards by which 
Business Unit Managers interact with the Process Manager, who has no authority 
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over them and cannot make them do anything. This is an example of the matrix 
organization based on a central coordinator. The coordinator (Process Manager) has 
no real authority, but must coordinate what all participants are doing. Without solid 
governance rules, this would be a formula for disaster. Responsibility without 
authority simply doesn’t work. But possessing the ability to appeal to a higher 
authority who can make things happen, does work for a coordinator. Setting the 
environment for this committee to operate is the role of the Process Manager and 
through him or her, the approach that is taken in Process Management Governance. 

As noted above, the end-product or Process Management approach will be unique to 
each company based on such factors as culture, placement of the Process 
Management role, and the authority that is given to the Process Management 
committee by the "higher authority" — the executive manager responsible for this 
function. 

Once the governance standards are defined and the approach agreed upon by the 
Process Management committee, Process Management Governance will become 
part of the overall change-governance structure in the company. This will include 
both Business and IT change-management and all the Centers of Excellence or 
Centers of Expertise in both groups. Overall, the Process Manager’s role in all change 
is to help managers evaluate change from a broader perspective and avoid a 
business-unit silo view. This is scaled to be both strategic for all change projects 
company-wide, and narrowly focused to help individual projects avoid causing 
downstream problems or contributing to the accumulated negative impact of 
myriad small changes in activity and rules. 

9.4.2 Governance Processes 

Process Management is defined by suggestion from the Process Manager and 
approved by each Process Management committee. The governance of this function 
is also suggested by the Process Manager and approved by the business managers in 
the various Process Management committees they belong to. The result is a set of 
procedures that combine to define how Process Management will be implemented 
in the company and, to some degree, in the various projects (flexibility is often 
needed at the project level and variances should be allowed to avoid overhead). 

Formally provided in this way, governance is itself a management process, and as 
such it is subject to the same forces that disrupt any process. Therefore, it must itself 
be re-baselined periodically to avoid white-space work creep and make certain its 
process is visible, controlled, and automated to the greatest extent possible. 

With BPMS support, automation can be generated from a governance process 
model, just as all business models in a BPMS can be used to generate management 
tracking and performance-measurement applications. All process simulation and 
improvement comparison will be measured against the baseline or initial iteration 
of the process. 
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9.4.3 Process Governance: Making it Work 

Process Management is a change-governance activity. It helps govern change and 
provides a broader perspective on the change process, with one purpose: to help 
coordinate change, making certain that changes are done in the right way and that 
none of them cause harm. 

Process Governance must be based on agreement among the business managers 
involved in any specific change project. Without their agreement, governance will 
not work and the benefits of Process Management will not be available to the 
company — at least not for that project. At a broader level, the same is true for 
Process Management. If governance is not agreed on by all involved and committed 
to by executive management, the move to a process view will not succeed. 

The real problem of process governance, however, is one of collaboration, as 
processes are becoming more complex and involve suppliers, outsourced work, and 
internal work that can be geographically located anywhere. Obtaining agreement in 
this environment is difficult, especially for a person who has no real authority over 
the work, but responsibility to make certain the process itself runs well and 
improves. 

Agreement among the participants, while vital, is not enough. Process Managers 
must eventually coordinate all process change. They must also report to a Process 
Officer who has the authority to make decisions about change and the influence 
needed to persuade managers to modify any changes to their operation that will 
cause harm to other managers’ operations. They must also have the mandate to 
work with the Centers of Excellence, both within and outside of IT, and with 
collaborative partners to ensure that changes actually benefit the greatest number 
of business units. 

In addition, it is suggested that companies moving to a process approach in 
controlling work create a separate process function that will tie organization 
managers who contribute to a process and likewise the Process Manager to the 
same evaluation metrics for performance and quality. This will provide incentive for 
them to work together as a process management team. 

9.4.4 Process Portfolio Management 

The cornerstone of governing enterprise processes is coordinating the enterprise 
portfolio of initiatives. To provide effective governance in accordance with overall 
process design, it is imperative that the process enterprise provides input or is 
directly aligned to the enterprise Project Management Office. 

9.4.5 Process Repository Management 

At the heart of process governance are the enterprise processes. To provide 
governance in a complex organization, it is important to have a common, 
standardized view of processes. In more mature organizations, these processes are 
typically managed in an enterprise process repository that is enabled by a Business 
Process Analysis (BPA) toolset. Additional governance frameworks should be 
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applied to the management of the enterprise process repository, which often 
overlaps with the overall governance structure. For example, process ownership 
would define the ability to make updates to or define the approver of process 
content within the repository. 

9.5 Business Process Management Roadmap 

Essential to establishing enterprise process management is a centralized plan to 
develop and deliver process capabilities for the enterprise. The Business Process 
Management Roadmap is meant to be the strategic plan for an enterprise to deliver 
Business Process Management over time. The BPM Roadmap will vary by 
organization, depending on current and desired maturity and overall process 
strategy. 

The roadmap should typically span several years and direct the ongoing activities 
associated with the process program. The roadmap should consist of multiple 
dimensions, including clearly defined goals, objectives, stakeholder analysis, and — 
tied to overall strategy — the defined activities and a time component. 

As described above, the roadmap can take on several instantiations, depending on 
numerous enterprise factors. To help manage the overall complexity of activities 
required, it is helpful to separate the work into two separate categories: (1) those 
related to specific process areas and (2) those related to developing the overall 
enterprise capabilities. 

9.5.1 Process Roadmap 

The process roadmap should include the required set of activities related to 
increasing the maturity or capabilities of a specific process area. For example, a 
roadmap should be developed specific to Order to Cash that depicts the overall and 
detailed programs and projects to drive value across the process. Process-area 
roadmaps should be managed by the overall process owner and integrated across 
the process areas. If the specific process area has been assessed as part of a maturity 
assessment, these results as well as any additional projects should be included here. 

9.5.2 Enabling Roadmap 

The enabling process roadmap would run parallel to the individual process 
roadmaps and depict the activities required to drive overall process maturity in the 
enterprise. Examples of elements within the enabling roadmap have been discussed 
throughout this section and include aspects of process maturity, process 
governance, process marketing, process education, and overall leadership 
development. Again, depending on the type of maturity assessment used, results 
and actions should be reflected in the enabling roadmap. 

9.6 Process Management Center of Excellence 

To concentrate expertise, many companies are moving to a Center of Excellence or 
Center of Expertise (CoE) model. In some companies we are seeing the creation of 
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specialty CoEs in both IT and the business operations to help focus skills and 
knowledge and provide help broadly to the business. 

“The key to CoE success is a combination of authority 
concentration and expertise in the BPMS(s), the technical 
environment of the company, an understanding of business 
operations, and BPM expertise. " -Dan Morris and Raju Saxena 
in a paper titled “The Need for a BPM Center of Excellence” 
(ABPMP). 


A Process Management Center of Excellence is needed (at least eventually) to 
provide consistency of approach through the creation of policy and standards at 
process level and lower, more focused Business Unit-level change, operation 
management, and a move to continuous improvement. This CoE will work with 
other company CoEs to coordinate standards and avoid overlap, conflict, and a lack 
of clarity. 

The need to concentrate Process Management expertise will become evident at 
some point in your company’s evolution to a process perspective — a perspective 
that allows managers and Project Team members to look at processes from end to 
end and drill down to any part of the process and the Business Unit that performs it. 
Assuming that a good BPMS is used as the base enterprise business modeling tool, 
managers and Project Team members will also be able to start at a Business Unit or 
greater level of detail, then follow the work upward to see the entire process, and 
model the ripple of changes to any part of the work. 

Process Managers (discussed above) may be part of this Process Management CoE 
or they may be separate and more focused on managing the process they are 
responsible for. If this is the case, the Process Managers will draw on the Process 
Management CoE to provide the guidance necessary for approach consistency, 
model consistency, reporting clarity and consistency, and Process Change 
methodology. 

This recognizes the role of the Process Management CoE staff as internal consultants 
that help Process Managers with change projects. As such, the CoE staff must be 
experts in the approaches, concepts, method, techniques, and tools used in Process 
Management and Process Change. They must be familiar with the standards, rules, 
and policies that will govern Process Management and Process Change in the 
company, and they must know the players and the politics in the company. 

9.6.1 Benefits to the Organization 

The main benefits to the business from a Process Management CoE are the delivery 
of Process Management consistency and the coordination of governance, standards, 
techniques and methodology used by the Process Managers. Just as their roles focus 
on consistency in coordinating work and change in their processes, they themselves 
should be governed and their work coordinated by common approaches and rules. 
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This is important in establishing any new CoE or taking an existing CoE to the point 
where it can support consistency across the company. 

But with consistency comes limitation. This limitation should not replace or prevent 
innovation and creativity in the way Processes are viewed, managed, or changed. It 
is rather the job of the CoE's internal consultants to promote these qualities in the 
projects that will improve the Process’s operation. 

Finally, the CoE will be able to work with the Data Architects to determine the 
"systems or sources of record" for data. These are the places where the highest 
quality data available can be found, which becomes the foundation for reporting. 
This will be supported by the creation of common performance monitoring and 
reporting requirements to make certain that the same type of information is 
available and reviewed by Process and Business Unit Managers on the Process 
Management committees. 

9.6.2 Typical Roles 

There are at least three distinct roles in Process Management. These are 

• The Process Manager, who will monitor all activity in the process and help 
the Business Unit Managers work with the other Business Unit Managers 
who contribute to the process and its products. This is a measurement and 
problem-solving role that involves creating and coordinating committees of 
Business Unit Managers who perform the work of the process. This role helps 
identify problems in the process, recommends corrective or improvement 
action, manages process-level change projects, and helps the various 
Business Unit Managers work together to govern the operation of the 
process. 

• The Process Change Manager, a role that may or may not be the 
responsibility of the Process Manager, who must focus on operational issues 
first. If this role is assigned to someone other than the Process Manager, that 
person should report to the Process Manager. The Process Change Manager 
is an advisor or internal consultant who is focused on change for the 
process — he or she is not operationally focused and is not involved in 
managing the day-to-day activities of the process. Rather, this person is 
responsible for improvement and controlling of the impact on upstream and 
downstream work of any changes in business operation, rules, data, or 
reporting. 

• The Process Consultant is an internal role provided by the Process 
Management CoE. People filling this role are experts in controlling process 
change and in the standards, policies, techniques, etc. that are used in the 
company to govern process change. 

9.6.3 Responsibilities 

Process Management involves only a few responsibilities at a high level. These are: 
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• Provide an end-to-end process view to Business Unit Managers who are 
involved in the process 

• Create Process performance monitoring and measurement 

• Coordinate the Process Management Business Unit Manager’s committee 

• Control change at the process level and review Business Unit Change to 
ensure that there is no impact upstream or downstream in the process 

• Provide consistency in approach, technique, and method 

• If there is a Process Management CoE, to work with the CoE to create 
standards, policies and governance rules. 


9.7 BPM Integration in Support of Process Management 

Process Management is very difficult to implement and perform without the 
implementation of a supporting BPM discipline and without BPMS tools. Why? 
Because of the scope of activity and information that must be dealt with. BPM is 
process- and workflow-oriented. As such, it is meant to look at process management 
and improvement. Since it uses workflow management as the foundation for 
process and activities as process building blocks, it is designed to help managers 
deal at all levels in the business. 

Second, the Process Management function can either focus on business and BPM or 
on the technical side and deal with Enterprise Architecture — which today is trying 
to move out of the IT infrastructure to include business process. ABPMP’s 
recommendation is, of course, to look at process from a business perspective and 
support improvement through the use of business redesign techniques and a BPMS 
tool suite. 

A third reason to integrate BPM and Process Management is the tools. BPMS tools 
provide the automated support needed to understand processes and monitor 
activity. These tools create a new operating environment that allows managers to 
track progress in near-real-time and add in Six Sigma quality monitoring systems, 
cost tracking, and more. They also allow Process Managers to work with Business 
Unit Managers and simulate proposed change at the process or the workflow levels, 
then look at the possible ripple effect of the change on other Business Units. 

Built-in security also allows the BPMS tools to control who views information and 
what they can do to it: read, add to it, or change it. This is critical in processes where 
parts of the work are outsourced or parts of the work are performed in different 
geographical locations. Because of the information-delivery capabilities (models, 
rules, etc.), these tools allow all managers in any part of the process to understand 
how their work fits in and how their staff contributes to the end product or service. 

Finally, the BPMS tools allow Process Management standards and policies to be 
translated into rules that will control work, decisions, governance, and reporting. 
These rules are linked to the Process and workflow activities and provide 
consistency. 
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9.7.1 Fit in the organization 

Process Management should be a separate structure in any company. It must be 
independent of the business units that support a process and it should have 
different performance targets than the groups it works with. In some respects, 
Process Management should be provided through a separate type of organization. At 
the top level is the Process Management Executive or Chief Process Officer who 
should report to the Senior Management Committee. The individual Process 
Managers or Process Owners should report to this executive manager. Process 
Change managers will report to these Process Owners. 

The Chief Process Officer is obviously responsible for the health of all the processes 
in the company. The Process Managers own the processes they are responsible for. 
These people will create Process Management Committees with the Business Unit 
Managers whose staff do the work needed to build the components of the process’s 
products or services. In doing this, the Process Managers will interact with IT, 
collaborative partners, outsourcers, and virtually all the Centers of Excellence in the 
company to identify problems, opportunities for improvement, cost-cutting 
measures, and quality improvement changes. They will also be responsible for the 
process view models in the BPMS and the (high-level) process business rules. 

Process Managers will work with their Business Unit Manager Committees to 
recommend projects and build business cases that the managers will agree to and 
sign. 

Process Change Managers will be responsible for modeling and governing change in 
the process. The most difficult part of this role is building the relationships with line 
managers and staff needed to identify low-level rule and activity change so they can 
be added to the workflow models and rules library. This updating is a critical 
activity needed to keep the operation and its models in sync. 

In addition, the Process Change Managers will be responsible for working with the 
BPMS and the Project Teams to model and simulate the change to identify potential 
impacts upstream and downstream in the workflow and process flow. 

External to this main Process shadow organization, but related to it, is the Process 
Management CoE. The CoE staff are process consultants who work with all levels of 
Project Management managers to advise them on standards, techniques, rules, and 
methods as they perform improvement projects and manage the processes. 

9.7.2 Role of IT in Process Management 

As with all parts of any business, IT provides the infrastructure that enables and 
limits automated support. This is as true in process management as in the Business 
Unit-focused application systems. The difference in supporting Process Management 
is that the applications are generally designed to support operational activity and 
not process. 

Today it is usually difficult to identify all the applications that support any process 
and the data they contain. It is also almost impossible to track activity across 
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processes and identify the status of work. This void can be filled through the use of 
BPMS technology, which can model the process and then monitor the movement of 
activity and the quality of work. However, this will mean that a process-level 
management structure will need to be built. 

Because this type of tracking and reporting cannot be effective when manual, some 
form of automated tracking and reporting is needed. Generally, this support can be 
built quickly using a BPMS, which can monitor work and add in metrics from other 
tracking applications in different parts of the process. This type of application 
support is needed to monitor activity and provide near-real-time dashboard 
reporting with alerts and inference-based guidance. 

However, building this support will require an appropriate IT infrastructure and a 
BPMS tool. That may or may not be possible in your current IT environment. It may 
be necessary to do the best you can using simple manual tracking, recognizing that 
this tracking will be high-level and incomplete. 

9.7.3 Enterprise or Business Architecture and Process Management 

Each of these approaches is unique and offers different support. But to form a 
complete picture of the business operation, all should be present: 

• Enterprise Architecture: A look at the business operation from a technology 
point of view. 

• Business Architecture: Alignment of the strategy of the company with business 
capabilities and through them to business functions and process 
components. That ties strategy and capability to process and Business Units. 

• Process Management: The end-to-end view and management of activity 
across the entire process and, at a lower level, the workflows that make up 
the process. 

Each of these disciplines and models adds something that the others miss. With a 
center of process, Enterprise Architecture provides a complete picture of how IT 
applications support activity and how the infrastructure supports applications. 
Business Architecture models provide a great picture of the business from a 
perspective of what needs to be done to deliver products or services. This defines 
effectiveness in the business. Process Management now adds the "how." It defines 
how work must be done and how it changes. Although it is difficult to do because 
these products and the groups that own them are separate, it is possible to pull this 
information together and offer a complete view of any process or any level of detail 
in a process. 

9.7.4 Continuous or Quality Improvement initiatives 

Process Management must deliver continuous improvement in all Processes and, at 
lower levels, support improvement in the Business Units. That is the goal of 
implementing any Process Management program. But to do this, the information 
that forms the view and defines the operation must be reusable, and the Process 
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Managers must be able to update and use the information quickly. If this is not 
available, the effort will slow and become overhead. 

Interestingly, as soon as anything becomes overhead it is deemed unnecessary and 
dropped. 

It is thus important that any move to a process perspective and Process 
Management be thought out and supported by executive management through 
budget and mandate. It should also be recognized that a move to this approach 
cannot occur quickly or without considerable work. Even with this support, any 
move to implement a continuous improvement program must provide an ability to 
change quickly — very quickly. The reason is that the business will change 
continuously and any change that takes a long time will deliver a solution that meets 
the old needs of the operation, not the new needs. So, speed of change is critical. 

This can be provided through the BPMS and its ability to quickly model and iterate. 
With this capability, changes in a process or at a lower workflow level can be 
modeled, simulated, tested, and deployed in days or weeks, instead of months. This 
also allows management to track the outcome of changes and make certain that the 
operation is improving. 
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Foreword by Dr. Mathias Kirchmer, Executive Director BPM and 
Global Lead Business Process Management-Lifecycle (BPM-L) 

Practice, Accenture 

Business Process Management (BPM) has become a management discipline that 
transfers business strategy into IT and people-based execution — at pace with 
certainty. BPM technology is key to delivering on this promise. It helps in creating 
the transparency necessary to achieve conflicting goals like quality and efficiency, 
agility and compliance, or internal alignment and external integration into 
enterprise networks. BPM systems enable the implementation of "processes to 
change" where this is appropriate. The high level of maturity of many components 
of BPM technology is also a reason for the increasing interest in BPM. Now BPM 
practitioners can focus on business outcomes and line up the necessary technology 
accordingly. We can move towards "value-driven BPM." 

BPM technology supports the entire lifecycle of a business process, from design 
through implementation to execution and controlling of processes. It supports the 
linking of strategy to processes through an appropriate design using Business 
Process Analysis (BPA) tools and converts that strategy into an agile execution using 
BPM automation engines. Process Performance Management and Business Activity 
Monitoring (BAM) systems shed light on running processes that enable effective 
controlling. New architectures, such as Service-Oriented Architectures (SOA), 
support the agility of IT-supported business processes even more. The resulting 
agility will again be increased through new approaches such as Software-as-a- 
Service (SaaS) or Cloud computing. BPM systems align software components with 
the business needs of processes. The use of social media resulting in "Social BPM" 
creates opportunities to integrate the people and IT dimension of BPM, delivering 
even higher performance of the powerful management discipline BPM. 

The agile BPM technology requires appropriate governance around it. This is the 
basis for creating real value through this new level of agility and scalability. BPM 
governance makes sure that technology is consistent with the people requirements 
and that both are aligned to produce best value for the organization. Governance is 
an integrated part of a BPM technology approach and strategy. 

The following chapter gives you an overview of the status and development of BPM 
technology, as well as the required governance component. It positions this 
important aspect of BPM in the larger context of an outcome-focused BPM 
management discipline that adds real value to an organization. 
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10.0 Introduction 

BPM is a comprehensive melding of Business Process Reengineering, Business 
Process Improvement, and Business Process Management methods and techniques 
that are designed to deliver both immediate and long-term improvement. These 
methods and techniques may be supported by Business Process Management Suites 
(BPMS) of tools to achieve Business Improvement or even Transformation. When 
combined, a new type of BPMS-supported BPM environment is created. 

This environment provides a new level of automation through application definition 
within the BPMS. Combining the logic shown in the business models with the rules 
and data that are linked to each activity, these tools then support the generation of 
business applications. This ability to define and generate supporting applications 
from models and rules allows the BPMS to offer unprecedented workflow 
management and improved flow-status reporting. It also improves control over 
work quality and activity timing. 

In this operating environment, the business activity is actually supported within the 
BPMS technical environment, with the BPMS controlling all aspects of IT support. 
This moves the BPMS to a controlling role in the orchestration of any support. As 
such, it is responsible for calling legacy applications, using what is needed 
(screens/functionality), controlling data use within the job that is being performed 
(following both traditional and Service Oriented Architecture — SOA approaches) 
and then mixing and delivering data where it will be stored. 

Although a BPMS-supported BPM operating environment offers many advantages, 
the three main benefits it creates are 

• Speed, through application modeling and generation 

• Quality, through an ability to externalize rules and then test them 
individually and in groups 

• Flexibility, through rapid iteration. 

10.0.1 An Introduction to Business Process Management technology 

The technology that supports Business Process Management is rapidly changing as 
every major vendor constantly monitors the competition and market in an attempt 
to read the market, anticipate corporate client needs, and offer features that make 
their suites easier to use and more functionally rich. 
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Business Process Management Operating Environment: 

BPM today melds Business Process Reengineering methods and 
techniques with Business Process Management Suite (BPMS) 
automation capabilities to achieve radical Business 
Transformation. In this emerging environment, the BPM teams 
use the full spectrum of BPMS tools to deliver business and IT 
change. Together, BPM and BPMS form a new operating 
environment that integrates new business management 
automation with legacy production applications to open access 
to data and functionality. This is usually created by considering 
most activity as web services and leveraging the power of the 
Internet to provide access and move information. The primary 
advantage of this environment is the speed of application 
development, the continuing improvement that can be 
delivered, and the flexibility it provides in changing the 
business operation and IT support. 


BPM technology has been changing rapidly over the past 15 years as vendors 
leapfrog one another in a race to provide the best business operating/change 
environment. In this race to provide support and thus capture market share, vendor 
consolidation has become a common occurrence. Two recent examples are Sawion 
(now Progress Software) and Lombardi (now part of IBM), both of whom have been 
purchased and are being integrated into other offerings. For example, Lombardi 
Blueprint has been changed by IBM into a product named Blueworks Live. 

This consolidation has been a significant factor in product-line extension and 
functionality enhancement, as vendors purchase parts of their overall product suites 
and then integrate them. Vendor partnering has also been common, as many 
vendors have incorporated other vendors’ components, such as rules engines. But, 
while this consolidation is common, some vendors, such as Pega, have resisted and 
have built most of their tool offerings. This latter option is now continuing as others 
are starting to replace partnered parts of their tool suites with internally developed 
or purchased offerings. 

Clearly, the BPMS marketplace is anything but stable. This trend is likely to continue 
as firms are bought and merged. However, this is actually far from a problem, as it is 
driving a rapid expansion of capabilities and a general improvement in product 
quality and stability. 

The past is clearly showing us that while tool evolution was fairly slow during the 
late 1980s and 1990s, it gained momentum in the early 2000s, and the pace of its 
evolution is increasing. Today, the various tool suites offer an unprecedented level 
of functionality and ease of use. And while many believe that the direction is clearly 
to move much of the traditional role of technicians to business professionals, we are 
starting to actually see a new level of collaboration as the roles of both the business 
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user and the IT technician blend in the analysis and definition of needs, rules, and 
data use. 

This blending is actually leading to a redefinition of roles and ways in which IT and 
the business operations interact. It will now not be long before the separation 
between IT and the business community, which has caused so much trouble in the 
past, will be reduced to simply dealing with the more technical aspects of data 
modeling and infrastructure. Among the key drivers in this bridging is the fact that 
the traditional way of looking at business requirements definition, the design of 
systems from specs, and the separation of data from the business in designing 
systems, is very different in a BPM environment, which makes the traditional forms 
to a large degree unnecessary. 

These and other approach differences are a direct result of the functionality 
provided by BPMSs and the fact that they provide their own operating environment, 
where the technology cannot be separated from the business operation. 

This chapter discusses these points and their impact on traditional IT concepts. It 
also looks at how this technology can be used to create a very different type of 
business operating environment. 

10.0.2 A Business Perspective 

The ABPMP CBOK will address this topic from a business manager or staff member’s 
perspective. This is thus a business-oriented discussion of a technical topic. 
Technical concepts and terms are discussed, but the discussions are not detailed 
technical discussions. They are rather presented in a way that provides the 
background that a business manager or a business-side BPM professional should 
have to understand. The presentation is thus fairly broad, but at a basic level to 
show how the BPM technologies work and the issues that must be looked at with the 
IT BPMS developer or BPM tool technician. 

Business managers and staff should read this discussion because it may well help 
them to understand the technical concepts, approaches, and considerations that will 
affect them. 

Technical BPM professionals should read this chapter because it will acquaint them 
with the issues and aspects of the topic that are important from their business 
client’s point of view. 

BPM technical standards and a detailed technical discussion are thus not addressed 
in this chapter. 

10.1 Evolution of BPM Technologies 

BPM technology has its roots in simple modeling tools. These tools were introduced 
in the early- to mid-1980s and evolved throughout the 1990s. In this evolution the 
tools became more capable of reflecting the business operation, and with the 
addition of rules engines and application generators in the early 2000s, the tool 
suites started down a different path — they evolved into application operation 
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environments with the generated applications being executed by and within the 
BPMS. 

Today BPM tools have evolved into two basic categories. These are standalone 
single-purpose tools and integrated groups of tools that together form Business 
Process Management Suites. The advent of these tools is fairly recent and they are 
still maturing. 

Standalone single-purpose tools 

These tools have provided companies the ability to inexpensively look at, and for the 
first time define, their processes and workflows. They also have allowed companies 
to look at their business rules and often uncover inconsistencies and conflicts. But 
their use is limited, and although they do provide good support, they do not allow 
companies to move to an environment where the models and rules can build new 
business operations and systems. 

BPMS 

Between 2003 and 2005 the fairly simple application-generation capabilities of the 
better tool suites underwent a change and evolved to provide a generation of 
industrial-strength applications capable of supporting complex logic and large 
transaction volumes. These tools became suites of modular products called BPMS, or 
Business Process Modeling Suites. Throughout this time, these tools also moved to a 
new status: they became business operating "environments." The applications that 
are generated are actually operating within the BPMS and the business now logs 
into the BPMS environment to run the business. Now the models define the business 
(context) and rules (logic, what data to get and from where, and what to do with it), 
and the forms provide the screen designs (within the context of their use). If an SOA- 
compliant data layer is available, the legacy application’s functionality is open and 
the legacy data can be easily found. 

But the evolution has not stopped with application generation. Today, many 
vendors boast simulation modeling that is capable of dealing with complex 
simulation. This allows companies to look at possible alternatives and select the 
best parts of these alternatives in order to come up with optimal business designs. 
And when SOA is added, companies can now change quickly by leveraging existing 
models and data, changing them, simulating the changes to reach optimal results, tie 
into legacy data through SOA, and then generate new applications. 

While this is possible now, it is seldom done. The reason is that few companies 
really understand that this is available and few have had the luxury of looking at 
BPM as a strategic tool suite instead of a way to deal with specific problems. But this 
use is changing and it will continue to change as companies realize the flexibility of 
this type of environment. 

10.2 BPM Technology: Enabling Business Change 

BPM technology has been evolving for over 20 years as it has moved from simple 
workflow modeling tools to complex integrated tool sets that provide a complete 
operating platform and environment. Today’s tool suites vary considerably in their 
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sophistication and function as many vendors try to supply tools for different need 
niches. But it is now possible to license very sophisticated standalone modelers, 
rules engines, simulation engines, performance modeling/monitoring/reporting 
and other special-purpose tools. It is also possible to buy closely integrated 
groupings of these tools to provide a seamless operating environment, as is found in 
the leading Business Process Management Suites (BPMS). 

The individual standalone tools offer model reuse, rules rationalization, operational 
visibility, and more. They have a place and are beneficial when used within their 
focus area. However, for a variety of reasons, some companies try to use these types 
of tools to provide support beyond their design intention. As with all tools, when 
used "creatively" (in unintended ways), they can encounter a variety of problems. In 
many cases, these "use pushes" are an effort to fulfill needs when tools cannot be 
switched to more functionally rich ones or where the company is locked into an 
inflexible technology environment. In these cases, the developers may have little 
choice, but extra care should be taken when it is necessary to "push" any tool 
beyond its intended use. 

While the individual standalone tools offer significant capabilities, these tools will 
not deliver the major benefits of the BPMS, such as speed of change (which allows 
companies to evolve quickly and optimize their operations), because they were 
never intended to do so. The integrated BPMSs, on the other hand, were designed to 
deliver a complete operating environment where the models and rules work 
together to generate applications that execute within the tool environment. 

In these tool suite environments, once the models are defined, the rules defined and 
placed in the tool suite’s rule engine, and the data is dealt with, operational change 
along with applications-change can happen very quickly. It is this speed of change 
that allows businesses to evolve quickly enough to optimize their operations and 
sustain that optimization. However, this ability is related to the difficulty in dealing 
with data and legacy applications. Companies that have moved to a Services 
Oriented Architecture (SOA) environment have the ability to deal with data quickly 
and effectively, supporting a faster method of change, than do companies that 
operate using the more traditional ways of dealing with individual application 
interfaces and data access. 

But even in more traditional IT environments, the BPMSs allow the users to move 
quickly in redesigning the business operation and how it will work. These tools also 
allow the analyst to capture supporting information and enter notes into the data 
screens that support each symbol used in the models. This information can then be 
viewed in a variety of ways and at different levels of detail. It can also be used in 
simulations. This allows IT to understand the data needs, legacy application 
interfaces, and data-use much faster than more traditional approaches. It also allows 
a much more modular approach to looking at functionality evolution and cost 
reduction. These modules are often referred to as services. This "modularity" is 
what allows data about the business, business models, rules, and more to be reused 
and simply modified at the model level to regenerate modified applications. 
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This delivers on two integrated BPMS promises: the advantage of speed of change 
and the ability to look at the operation at various levels of detail with immediate 
access to relevant information on how the operation really functions. 

However, stepping back from the high-end BPMS products, significant benefit can 
also be realized from individual modeling tools, rules engines, SOA and other BPMS 
components. For example, many businesses have never had the advantage of an 
end-to-end detailed view of their business operation or processes. Many more can 
gain serious improvements in simplifying IT and in opening access to data through 
SOA. So BPM is not an all-or-nothing prospect, nor is it a one-size-fits-all approach to 
improvement. But BPMS product flexibility does suggest a need to create a BPM or 
business improvement strategy and then build the business and technical 
operations to adhere to it with its tool use and implementation standards. 

This chapter provides the foundation needed to consider how a BPMS-driven BPM 
environment can provide a competitive advantage and how the use of individual 
BPMS tools can start you down a path to control the evolution of the company. (See 
"Evolutive Management" in chapter 5.) 

10.2.1 Overview of BPM Technology 

Business Process Management Suites (BPMSs) provide a new type of business 
environment that melds the business and IT. We use the term "environment" to 
describe the resulting operation when using a BPMS, because these tool suites 
generate the applications and provide the overall operating environment through 
which the business and the applications run. 

Through the business models in these tools, the context for the business operation is 
defined as a step-by-step framework of the business operation. From these models, 
the requirements for the data use, legacy use, and technical support of the operation 
are defined. When the screens are defined (as forms) in the business designs, they 
provide the touch-point interaction locations and data use requirements for the 
business worker. When the rules are defined and added to the design, they deliver 
the logic or "thinking” that the system will do to support the operation. With forms 
and rules together, the BPMS can now simulate possible design scenarios and 
evaluate outcomes based on testing that mirrors the real way the application will be 
used. As part of this simulation, the applications are generated and tested — along 
with all interfaces to legacy applications and other BPMS-generated applications. 
After testing, the applications are moved to "production" and the business is 
supported by executing these applications according to the framework shown in the 
business workflow maps and the rules that define the logic. 

The data and interaction between people and applications are defined by form and 
supporting database schemas in the BPM tools suites, and the data use and 
transformation are directed by rules. To provide the data needed to support the 
data call rules, it is usually necessary to define and construct interfaces to the 
current applications and their databases, as well as to current data marts. In 
companies using SOA tools, these interfaces can be simplified through the use of 
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adaptors that help define the interaction and the systems that will deliver the flow 
of data between applications. 

Together this forms a complete operating environment where the business 
operation is performed within the BPMS environment. However, without the 
necessary modules from a complete BPMS, the environment will not be able to 
generate applications, and the benefits from flexibility and speed of change will not 
be available. 

Although you may not be able to address all issues or solve all problems with any 
tool suite, you will never solve any problem or make any improvement unless you 
actively look at the operation and how it functions. This is not a one-time activity. It 
is constant, and it creates the foundation for continuous improvement. In addition, it 
is necessary for management to be open to ideas and innovative solutions. No one 
can provide all the ideas or answers, but managers with closed minds seldom 
achieve the changes that those who are willing to try new ideas achieve. It is 
important to build a change environment that promotes "outside-the-box" thinking 
and controlled improvement experimentation. Apart from these qualities, it is 
necessary for management, in order to be effective, to support improvement ideas 
with a change environment that allows the ideas to be quickly defined, designed, 
simulated, built, tested and implemented. That is where the BPMS technical 
environment comes in. This environment (supported by a full BPM technology 
suite) delivers the ability to support thought and then quickly to turn that thought 
into deployable action. This is why a BPMS technical environment, when used to its 
fullest, can provide a competitive advantage. 

10.2.2 What is it? Capabilities 

The term "BPM technology" today means different things to different people — even 
within a single company. The differences start with the differing perspectives 
between business and IT. In business, the term BPM technology can refer to 
something simplistic and limited, such as the use of tools like Visio for simple 
modeling, or it can refer to the use of complex tools and full BPM Suites (BPMSs) for 
complex modeling with rules definition and generated operating applications. This 
side of BPM is focused on improving business activity and is limited to the process 
optimization aspect of change. In addition, some organizations with more advanced 
document management systems are now being told that the document management 
tools are BPMSs. We will leave that as a "matter of opinion." However, even these 
tools do have simple workflow modelers. 

From the IT perspective, BPM tools have often focused on Service Oriented 
Architecture (SOA) and Enterprise Application Integration (EAI). These tools are 
important to IT and are the foundation of a move to a very different architecture for 
application integration and data delivery. Of course, this perspective leaves out the 
process modeling and rules tools, which are business-oriented. At times this 
technical perspective includes an Enterprise Service Bus (ESB). This gives the IT 
group a focus on application interfacing and data delivery. 
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In addition, just to make things interesting, both the business and IT sides are now 
looking at adding Enterprise Architecture tools into the mix. These tools can have 
fairly advanced modelers and add the ability to model the technical architecture, 
data architecture, and more on the technical side. These tools may soon "muddy" the 
BPMS discussion, but for now, we can still consider them as a separate group of 
enterprise modeling tools mainly for IT. 

From the ABPMP perspective, BPMS technology includes both the Business 
perspective and the IT perspective on tools and technology. It is thus broadly 
encompassing and BPM Professional Practitioners are expected to understand both 
sides of the technology, Business and IT. To have "understanding” does not mean 
that business professionals are expected to become technicians or that technical 
professionals must become business operational managers. It does, however, mean 
that each group should have a good understanding of the needs, work, and tools 
used by both, and how the tools and their use fit together to allow rapid, continuous 
change in a controlled new operation. 

In addition to the general Business/IT difference in perspective, the differences in 
definitions of BPM and its technology continue, based on company and department 
perspectives. 

The problem is that many people look at BPM according to their company’s 
definition and the functionality BPM technology provides to their team. 
Comprehensive as it may be, a company perspective is often an incomplete view 
because few companies use BPM or a BPMS to its fullest (use complete sets of BPMS 
tools and all or most of the features). Also, because many companies have used BPM 
only in specific solutions, the tool suites are often not kept up to date and the 
company view may be based on experiences with prior versions of tool sets that are 
more limited than today’s capabilities. 

Adding to this definition and concept problem is the fact that many companies are 
now using multiple BPMSs from different vendors. As each vendor uses terms 
differently, the various departments will have a different vocabulary and different 
meanings for common terms. When added to the differing definitions for commonly 
used terms within a single organization, the communication issue becomes a serious 
impediment. 

Terminology, concept, and sophistication can thus be expected to vary among these 
groups, as do approaches, an understanding of what a BPMS can do, and the way 
data access and use are governed. 

The differences in perspective among groups become even more complicated when 
the use of the tools is limited to specific purposes for different groups — such as the 
use of process modelers for business people, the use of rules engines for technical 
people, the generation of applications as a technical function, the creation of forms 
as a business function, and so on. This limited use also narrows people’s exposure to 
BPM and BPMS tools and can impact their understanding individually or as groups. 
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While the capabilities of BPM tools and BPMS change constantly as the vendors add 
new functionality in their effort to compete, some version of this core functionality 
will include 

• Process modeling 

• Simulation of new designs 

• Rules definition and management 

• Performance reporting 

• Application generation (usually somewhat limited) 

• Service Oriented Architecture (SOA)/Enterprise Application Integration 
(EAI) 

• Enterprise Service Bus (ESB) 

The features and capabilities of these functional components vary today and can be 
expected to vary in the future. Any look at capabilities is thus time-dependent and 
any study must be focused on current information. An overview of the core support 
in these major areas is provided in section 10.3. 

As shown in Figure 67, BPM tools can be viewed as providing distinct functionality. 
Some provide full functionality and others are focused on one or two levels in this 
hierarchy. The placement of the function on this diagram indicates its relationships 
to the business on the top and IT on the bottom. 

The categories of levels will be discussed in 10.3, but their relationship is driven 
from the top of the model in Figure 67 by the business needs, or from the bottom by 
the IT need to better control data access and use. The Rules Engine can be used with 
all levels and spans the use of all tools. However, the Rules Engine will seldom be 
used alone except by IT to help get a handle on the rules in legacy applications. 

The technology layers are at the bottom of this model. They primarily deal with 
data, data access, data manipulation, data delivery over the Internet, and interfaces 
between applications. 

In use, the process modeling tools feed the simulation tools. The simulation tools are 
primarily found as modules in the more advanced BPMSs. However, not all of the 
BPMS tools have this capability. These tools allow the business and IT managers to 
look at "what if" scenarios. Business model designs, with supporting volume and 
other information, are modified to represent different business scenarios and tested 
in the simulation tool. The new business workflow design and the rules feed the 
application-generation modules in the BPMSs and drive the need for, and 
requirement for, legacy application use, data access, and interfacing. Performance 
Management (monitoring of real-time work and measurement of trends with BI 
reporting) can be built into the prototype new designs, to help determine the 
optimized design within the simulation tool. The BPMS applications can then be 
generated and used in "live” simulations of the new business with its applications. 
Legacy application-use and legacy data can itself be added to the simulation to form 
a complete version of the business operation. 
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Different versions of the business operation can now be easily built and tested. In 
this approach, Six Sigma-related tools are linked to the generated applications and 
help point to areas of improvement, which are then monitored. 


BPM Functionality 



Performance Monitoring 
and Measurement 


EAI/SOA 
With ESB 


Figure 67. BPM Functionality 


Once the optimal solution is proven, interfaces to legacy applications’ functionality 
and data can be built (using either SOA or a traditional single interface construction) 
and the final application can be moved from the simulation environment to the 
production environment (within IT) and implemented. 

It is this capability that allows both the business and IT to continually look for 
improvements and quickly respond to new business and application requirements. 
In this new operating environment, change is quickly analyzed within the BPMS 
models; a solution is simulated and then once optimal, moved into production. 
Optimizing here is a fast, iterative process where the solution is honed using 
performance measurement tools and business-user "use testing." In the BPMS 
environment these iterations can be built and executed within hours and new 
business operation (with workflow, application, management control and other 
changes) put in place. 

While these tools can be somewhat unbundled, they only deliver the real promise of 
BPM (speed of change) when they are all used together. This is important because it 
is only when this speed of change is delivered that business optimization can be 
reached. 
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Delivering this speed of change requires an initial investment in the creation of 
business process and workflow models, the definition of business rules, and the 
baseline models and interfaces for simulation and deployment. This creates a new 
integrated business/technology environment. Changes are now made in the BPMS, 
and (BPMS) applications are regenerated. Interfaces, however, still need to be 
changed. Testing now needs to take place in the business and in the normal IT 
testing done by the company. The time-frame in this environment is very different, 
with business changes that once took months or over a year, now compressed into 
days or weeks. 

This capability is the biggest benefit of a BPMS-supported BPM operating 
environment. It is also the advantage that can be gained from using a BPMS rather 
than separate process modeling tools and separate rules engines. 

10.3 Capabilities of BPM technologies 

Components: Process Modelers , Application Generators, Rules Engines, Performance 
Monitoring, EAI/SOA, ESB 

To help focus on core capabilities in the diagram below (BPM Tool Use), rules are 
included in Process Modeling, and Enterprise Service Buses are included in the 
EAI/SOA group. The BPMS data repository is included as part of each level. 
However, it is generally appropriate to use databases that are external to the DBMS 
for serious applications. 


Examples of Tools 
Comprising a BPM layer 

Enterprise Process 
Modelers, Rules Engines. 
Business Simulation 


BPM Product Suites 


Reporting tools such as 
SAS, Custom 
measurement tools, 

BPM Product Suites 
EAI Tools, SOA Tools. APIs. 
Database tools ESB tools 


BPM Tool Stack 


{ 
{ 
{ 

{ 


Application 

Generation 


Performance 

Monitoring 


EAI/SOA 


} 

} 

} 

} 


Tool Use 

Current and Future State 
Process and Workflow 
Models, Rules Tables 


Executable Application 
Definition/Ceneralion 


Workflow Monitoring, 
Operational Performance 
Measurement, Decision 
Support Foundation 


Interface Legacy 
Applications, deliver SOA 
defined 'Services’, and 


Figure 68. BPM Tool Use 


BPM Tool Use 

shows the relationship between the functionally oriented tool groups and defines 
what each group supports. Business models contain the definition of the activity, its 
flow, its rules, its data use, its user interface, and the way performance will be 
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monitored. Here, detailed business process models are used to drive application 
generation. The application generation will support the simulation of the design 
iterations until an optimal design and supporting applications have been identified. 
The "solution" will then be put into production, and performance measurement and 
analysis will occur. If this solution will be supported by legacy data and legacy 
application functionality, the solution will be interfaced with legacy application 
through SOA adaptors and web services. The data will be moved across an 
Enterprise Service Bus. This, of course, assumes that all layers are in place. But, as 
discussed earlier in the chapter, it is very possible to use special purpose-tools or 
tools that apply to only one or two layers in the model. 

Currently, the major BPMS tools operate on local company-based hardware servers. 
However, most vendors are now moving to offer their products through a form of 
network "cloud”-based services. These offer a different architecture and a different 
form of billing — usually on a transaction basis. It seems clear that a greater variety 
of architecture/use offerings will be available to companies using BPMS tools. While 
the variety is difficult to predict, security will likely remain a problem, as will data 
integrity. For many companies, these issues may limit options, as use and data may 
need to remain locked behind the corporate firewalls. 

Although similar in many ways, in reality each vendor’s tool suite modules and 
functionality will vary. Some are narrowly focused and some provide modules that 
perform a wide range of functions. In addition, some vendors have "integrated" tools 
from other vendors into their product offering and resell these modules as part of a 
complete tool suite. Because of acquisitions, the playing field among these vendors 
is constantly changing, with major companies like IBM and Oracle augmenting and 
changing their offerings by purchasing higher-end BPM vendors. 

This tendency creates a temporary instability in the market as vendors adjust their 
offerings and decide what they will keep, modify, and eliminate. While this should 
eventually create better products, in the interim, it does increase the risk of any 
commitment to a specific vendor. 

Some vendors will also require the person using their tools to be much more 
technical. Open-source BPMS are an example of this and require a great deal of Java 
coding to drive the products behind the scenes. Other mainstream products, such as 
Pega, also fall into this "technical" category. So, "user friendliness” can be a major 
concern and could be considered more important than a BPMS’s functionality or 
cost. 

Although the past focus in BPM on using a BPMS for specific problem-resolution 
efforts has caused many companies to purchase multiple BPMSs, any more strategic 
use of BPMS technology will likely mandate that the company move to a single 
vendor or a least a limited number of BPMS vendors. A company looking at a vendor 
consolidation or moving to centralize on a single vendor should consider, in 
addition to functionality and usability, several factors. These include: 

• The vendor's plans for the modules in their product. Will any products be 
replaced or sunset in the next three years? If you make a commitment to 
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their product, how will they help you migrate to the new version? This is a 
problem today with some vendors as they continually move to new products 
and versions. 

• Is the vendor for sale? What will be guaranteed if the vendor is sold? You 
will want to be assured that some products will not simply be dropped by the 
new owner. Many vendors have been purchased in the past three years. This 
trend will continue. How will it impact you? 

• Alliance stability: are vendors strategically and legally committed to 
continue supporting any integration of products? If a vendor alliance is 
dropped, what will be done to assure your continued use of the full product 
suite and how will the vendors work to continue your support? 

The next section describes the main BPM technologies. They are: 

• Business Process Analysis Tools (BPA) 

• Enterprise Architecture Tools (EA) 

• Business Rules Management Systems (BRMS) 

• Business Process Management Suite (BPMS) 

• Business Activity Monitoring (BAM) 

• Service Oriented Architecture with Enterprise Application Integration 
(SOA/EAI) 

• BPM Enterprise Repository (external to the BPM tool alternatives but 
needed) 

Note: While Enterprise Architecture tools are usually not considered a BPM 
technology, they are needed to help evaluate the current IT environment’s ability to 
support a new business operating design. 

The following discussion looks at the major modules or components of BPM tools. 
This discussion is not meant to look at all possible components and it does not 
attempt to comply with the naming convention of any vendor. The table below 
shows the main BPM support tools and some of their main uses. 



BPM Tool Alternatives 

Core Use Cases 

BPA 

EA 

BRMS 

BPMS 

BAM 

SOA/EAI 

BPM 

Repository 

Process Analysis (cost, 
time, others) 

Yes 

Yes 


Yes 




Comprehensive Process 
Modeling 

Yes 



Yes 

for most 




Business Process 
Architecture Design 

Yes 



Yes 




Simulation 

Yes 



Yes 




Data Management 


Yes 


Yes 



Yes 
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Application, Hardware, 
Information 
Architecture Design 


Yes 






Application, Hardware, 
Information 

Architecture Monitoring 
/ Management 


Yes 






Design and store 
business rules 



Yes 

Yes 




Execute business rules 



Yes 

Yes 




Application Interfacing 




Yes 


Yes 


Application Generation 




Yes 




Process Execution 




Yes 




Process Measurement 




Yes 

Yes 




Table 28. BPM Tool Alternatives 


10.3.1 Business Process Analysis (BPA) 

Process and Workflow Modelers 

Modeling tools (BPA tools) allow business managers and staff to enter diagrammatic 
and detail information about their operations and the problems, volumes, 
opportunities, etc. associated with the activity. To control the use of these tools it is 
critical that a company standardize symbol use, modeling approaches, and 
terminology. For many companies that have multiple BPA tools, this will be difficult: 
not only will it be costly, but it will be a politically-charged, high-risk activity. 

Modeling tools typically allow the person entering the model to define the activity in 
the business by clicking on a given type of symbol and dragging and dropping it onto 
the model page. The placement of symbols can usually be changed easily by clicking 
and dragging the symbol to where you would like to put it. This is true for all the 
different symbols that can be selected from the symbol list. Each symbol is made 
unique by the label you give it and the information that is entered to support it on a 
detail data-form that can be reached by clicking on the symbol once it is placed. 

Flow is defined by the use of various types of connectors. Some connectors can have 
information on what is passing associated with the use of the symbol. Decomposing 
a symbol happens in different ways in different BPA tools, but most can support it. 

The information that can be collected by BPM modeling tools is somewhat standard, 
but it will vary by tool depending on the supported modeling methodologies. In 
some tools, the modelers can support a limited amount of "company specific" or 
user-defined information collection and retention. In others, the user will be limited 
to the data that can be collected through attributes associated with a given symbol 
used in building the graphical model of the business operation. This is important, in 
that it will allow or limit flexibility in a company's symbol-use and data-capture 
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standards. It is this standardization that allows model, object, service, information 
capture, etc. reuse within the company. 

To the extent supported by the vendor, the definition of these data fields should be 
reviewed during the tool’s setup and the definition of the underlying data model and 
schemas that will be associated with the tool’s database, models, and data-selection 
menu (for dragging and dropping data elements in models). 

Process Modelers’ features include: 

• The ability to identify and define activities or work steps; this can be through 
swim lanes or through a free format diagramming technique 

• Hierarchically associate the levels of detail 

• Show where rules apply — decisions, etc. 

• Associate notes or other information with the activity 

• Enter details about each symbol’s volume, data use, screens, etc. 

• A way to link the activities into a type of flow showing the placement of each 
activity relative to the other activities that need to be performed 

• Build processes and workflows 

• Decompose any activity into lower levels of detail 

• A way to show activity by user role (swim lanes; each swim lane is definable 
by role or department) 

• The ability to capture supporting information about each activity 

• Volumes 

• Value ranges 

• Timing 

And more: 

• A context to capture rules that control the operation, and interface to a rules 
engine 

• Identify and associate rules with activity 

• Determine rule redundancy etc. 

• Build in data quality requirements 

• A context to identify and associate reporting and auditing activity 

• Six Sigma tool application 

• Data collection points 

• Work quality checks 

• A framework to associate the use of application systems and the use of data 

• Define the data that can be entered for symbol definition and background 

• Define the data on each application screen 

• Define the edits and other quality checks for new applications 

• Define the way data will be used through rules 

• The ability to design screens that will be used at any point using forms 

• Iteratively design screens with the people who will use them 

• Align screens to data and rules 

• Change screens and data quickly 
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• The ability to link to a business simulation module (some BPA tools cannot 
support simulation) 

• Simulate the use of changes and their impact 

• Create multiple models to see what changes work best 

• Ability to support testing 

• An ability to track performance information capture into the models — 

• Track performance for each individual 

• Track performance at the process or workflow levels 

• Collaboration software including electronic communication tools, 
conferencing tools and management tools. 

• Multiple concurrent users 

• Multiple locations 

• Team use of information 

Note: These tools often take advantage of the Internet and provide web-based 
applications that are supported by web browsers. 

10.3.2 Enterprise Architecture (EA) 

Business workflow, Data Flow, Data use. Applications tied to workflow 

Enterprise Architecture is a model of the business operation that defines the 
structure of the organization and how it can achieve its current business 
requirements and its future goals. The basic viewpoint of EA is fairly technical. It 
includes an application viewpoint, a data viewpoint, and an infrastructure 
viewpoint. These perspectives are centered on a business view that serves to tie the 
others to business organization. 

This area of work is changing today. In the past, Enterprise Architecture was really 
an IT technology architecture for the business. This was a model of all the hardware 
and its supporting technical software: operating systems, middleware, and tools. It 
included applications — especially when ERPs or other large systems (integrated 
groups of vendor application modules, such as Health Information Systems) are 
used. The Enterprise Architect’s focus is on using technology to solve business 
problems. To many, this is interpreted as modeling the entire business and its IT 
support and then applying IT to solve all business problems. 

Although this discipline still reflects its technical roots in the capabilities of EA tools, 
its scope and focus are expanding to include business concerns. In EA modeling, the 
models will use a type of process model as the central model. This is usually a 
higher-level look than in BPMS or BPA tools. These models usually follow one of two 
basic approaches to business definition — TOGAF or the Zachman Framework. 

The Enterprise Architect is concerned with the structure of the organization. This 
often includes business strategy, process, business and IT infrastructure, 
organization, and culture. In modeling, the EA models may include these 
components and external components that affect the business. 
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While the EA core models include process models, EA tools often have a technical 
view that is lacking in a BPMS. This allows them to look at the way applications tie to 
activity and how the applications then link to one another and how data flows 
between these applications. 

Note: In Enterprise Architecture (EA) tools, a technology perspective is added to the 
business view. 

EA tools, however, have limitations in other business modeling areas, but will at 
some point likely compete with traditional BPMS tools. Generally, the EA tools are 
used for a different purpose than BPMSs and are not good at rapid iteration because 
they usually lack simulation capabilities or good ways to decompose process or 
workflow diagrams to lower levels of detail. However, their use in relating hardware 
and software to business activities forms a very different and useful picture of the 
enterprise and IT support. Most of the more advanced EA tools offer a great deal of 
functionality in requirements definition and management with an ability to track 
requirements through the systems development lifecycle, generate applications in 
one or more languages, reverse engineer legacy applications, database modeling, 
application debugging, and more. Collaborative processing is also supported in most 
of the tools, with security over access and change. 

Although many EA tools use BPMN to define symbol use, the tools generally have a 
difficult time interfacing with a BPMS. This can be a problem because it means that 
EA and BPM models will require two different tool suites, and that the models may 
easily get out of sync. 

As EA becomes more attuned to the business operation and less IT oriented, it will 
cross boundaries with Business Architecture and Process Architecture. This will 
likely cause confusion over roles and responsibilities that may be reflected in tools. 
However, today there is still a distinction between the more physical view of EA and 
the more conceptual focus of Business Architects on Business and Technical 
Capabilities as they relate to strategy. But both eventually consider process, which is 
the realm of the Process Architect. So, we can expect considerable overlap and 
shakeout as these disciplines sort out their boundaries. 

10.3.3 Rules Engines or Business Rules Management Systems (BRMS) 

Business Rules Definition, Rules Storage, Rules Access by Applications 

Business and technical rules define how work will be performed in each activity or 
step in a workflow or, at a higher level, a process. They are the "institutional 
knowledge" of the company and they are the real competitive differentiator of the 
company. They define who will do something, what they will do, when they will do 
it, why they will do it, how they will do it, and how it will be controlled. From a 
technical perspective, rules are the logic of the business. 

Rules Engines are tools that support the identification, definition, rationalization 
and quality of business and technology rules. Rules Engines also provide a 
repository that allows rules to be checked against one another for definition or 
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context problems, and thus checks for redundancy and definition quality. These 
engines today tend to be fairly technical in nature, so the definition of rules in these 
products tends to require both training and experience in technology and in 
business. 

In practice, rules are looked at as "if — then" statements: "if” (an event or value), 
"then" do something. Because the list of things that must be considered in any 
decision can be fairly long and complex, rule definition can be a serious undertaking. 

Rules tend to fall into one of several categories. These include 

• Business operation rules 

• Decision rules 

• Flow sequencing rules 

• Procedural and Policy rules 

• Data use/security rules 

• Access security rules 

• Monitoring and reporting rules 

• Technical rules associated with data calls, data transformation, application 
interfaces, etc. 

• Legal rules 

• Financial rules 

• Monitoring and measurement rules 

• Regulatory rules. 

While this list of categories is fairly representative, it must be customized to each 
company and used to create the internal architecture of a rules repository. This and 
other definition functions allow the setup of the Rules Engine to work at an optimal 
level in your company. This definition is not trivial and should be carefully 
considered prior to the implementation of a Rules Engine to maximize its use and 
company benefit. 

Rules definition and coding is critical to the way a generated application will 
execute. If the rules are too complex, the execution will be slow. If they are long and 
test for a long list of conditions, they will be slow. If they call multiple databases, 
they can be slow. If too many slow rules are placed in a row, the execution of the 
application will be slow. For these reasons, the coding and use of rules should be 
carefully checked and standards customized from a list of best practices provided by 
the vendor. 

The biggest problem in most companies is that business rules are not well defined 
or organized in current procedural manuals. Few companies really understand their 
operating rules or have them formalized — especially low-level business execution 
and decision rules. In most companies, rules simply do not work the way many think 
they do. That is because people at the execution level must find ways to get their 
jobs done and they interpret and change rules constantly. 

Rules are virtually everywhere in companies. In some cases they can be found in 
procedural manuals or in policy manuals. In other cases they are in memos, notes, 
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emails, and just "folklore." They are also embedded in legacy applications and in the 
implementation of licensed or purchased software. They are everywhere in the 
business, but they are almost never in one place. 

This has serious implications for the selection and use of a Rules Engine. It is also a 
reason that many rules projects are driven from IT, where they are needed to define 
how applications will work. Regardless of who or what is driving the move to 
identify, define, and rationalize rules, the technology must be able to accept entries 
from multiple business units and merge the rules to create common definitions, 
versions, synonyms, antonyms, etc., as it brings rules into a common repository and 
ensures their quality. This use has implications for access, security, and change 
abilities. So, it is important that a Rules Engine be able to conform to the realities of 
the way you need to use it in your company. 

It must be noted that the definition of a rule for entry into a Rules Engine for storage 
and use in a Rules Repository is not a simple activity. Rules are complex, and their 
definitions need to be complete before entry. They seldom stand alone and must be 
defined in complete sets of decisions and organized in a well thought-out structure 
that supports the way they will be executed by an operation or program. 

This must be considered in the setup of the Rules Engine and the Rules Repository. 
Following this setup, the rules must be translated into a type of computer program 
code for entry. The better Rules Engines will do a variety of complicated syntax, 
relationship, and other testing as the rule is entered, but it is important that the rule 
be defined correctly and checked, because it will be used to generate BPM 
applications and to run the business. 

Common Rules Repository use includes 

• The capture of an organization’s institutional knowledge in a central place 

o The definition of rule templates for specific customer interactions, 
such as action compliance, cross-sell, up-sell, and more — including 

■ Scorecard — based on scoring and ranking 

■ Decision Tree — based on if-then logic 

■ Decision Map — based on one or two explicit input values 

■ Decision Table — based on a series of test conditions to be 
evaluated 

o The creation, alignment, testing and deployment of rules 
o Rule storage for company wide access 

• Finding currently defined rules and their definitions: 

o Direct flow logic and execution steps in business modeling 
o Use in BPMS applications generation 
o Design legacy application modification 
o Determine legacy application interfacing design and needs 

• Supporting rule execution by programs and managing rule use 

o Elimination of rule conflicts and redundancy 
o Identification of rules that no longer meet legal requirements 
o Improve rule quality — clarity, consistency, and editing 


388 


Copyright ABPMP International 



Chapter 10. BPM Technology 


• The analysis of Service Level Agreements, Key Performance Indicators, Six 
Sigma formulae, and more 

• Management of the quality and integrity of the rules and rule sets 

o Manage changes to rules 
o Manage the creation of new rules 

o Provide a picture of everywhere the rule is used to determine how it 
should change 
o Test rule use 
o Manage access to rules 

• Building what-if analytics to analyze inter-related rules and rule use 

o Historical and runtime analytics 
o Deploy rules to target programs and BPM use 

• Validation that the right data is being used by the rules 

• Data use, editing, testing, and legacy data use. 

Benefits that can be expected from a Rules Engine include 

• Externalization of rules in a standard format, using a standard vocabulary 

• Place all rules in a single central rules repository 

• Expedite program changes by having all rules and their uses cross- 
referenced in a single place 

• Flexible rule definition — legacy applications, interviews, documents 

• Improve rule definition quality — provides consistency in rule reuse 

• Rule definition and testing support — redundancy, "holes," logic, etc. 

• Version control 

• Improved rule visibility 

• Ability to evolve applications and business operations faster by dealing with 
external rules 

• Make a change in one place and have it applied everywhere the rule is used. 

10.3.4 Business Process Management Suites (BPMS) 

Process Modeling, Workflow Modeling, Rules Definition, Business Operation Simulation, 
Application Generation, Business Operation Environment, Management Reporting 

A BPMS is a suite of tools that form a joint IT /Business operating environment. Here 
the business runs within the BPMS environment. By this we mean that when a 
person starts their work and logs into an application system, they are logging into 
the "run time" part of the BPMS. This "run time" part is where the models and rules 
are executed. 

In a BPMS the business process models are built of BPMN symbols. These symbols 
represent tasks, decisions, automated actions, etc., and each is unique in that it 
represents a type of small, single-purpose computer program module. These 
program modules are arranged and run (executed) in the order defined by the flow 
in the business process models. The program code of these modules has blank 
spaces that are automatically filled in by the BPMS with the rules that the business 
models associate with the symbol’s use and the data that the models tell the system 
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to use. Screens are defined as forms and associated with tasks within the BPMS. 
Reports are also defined. 

Exits from the business process models to legacy applications or other programs can 
be put into the business process models to call other applications and form a series 
of automated tasks. Although a type of interface is still needed, Service Oriented 
Architecture (SOA)-use with Enterprise Application Integration (EAI) adaptors and 
accelerators make interfacing in this environment much easier and thus reduce time 
and risk. 

Special management controls can also be added to the models to control workflow 
volume, work routing, delay alert, etc. These should be standards-based, but the 
BPMS can support almost any company standards. 

Rules are entered in coded form and the rules-engine part of the BPMS keeps track 
of every place the rule is used. Changes to any rule are made in the rules engine and 
then called by all the business workflow models as they are executed. This greatly 
simplifies changes. 

Performance measurement can also be added to the workflow models and specific 
measurements are created through rules or exits to other measurement programs. 
This is where performance disciplines such as Six Sigma, Lean and BAM (Business 
Activity Monitoring) are used, by embedding their performance-monitoring 
approaches or programs into the new designs. The results can be used to feed 
complex dashboards and provide warnings with recommended actions — again 
based on rules. Many BPMS tools also allow you to define forms that can be accessed 
from a symbol to capture screen and report-related information. The tools that can 
generate applications allow the designer to create models of data-capture and 
lookup screens, as well as reports. The more sophisticated tools also allow you to 
link legacy applications (at the function and data level) to the symbol’s use in the 
business flow. Of course, the tools that can generate BPM applications allow you to 
link rules directly to the activity symbols for BPM application generation. 

This environment is easy and quick to change. Most changes are model-based or 
rules redefinitions or additions. To help ensure the completeness of the change, and 
reduce risk of error or data-quality harm, any change can be quickly simulated using 
the simulation capability in most BPMS. This allows the team to iterate quickly until 
an optimal solution is ready. Implementation is really a matter of a software switch 
and any retraining needed. 

10.3.4.1 BPMS setup 

All of the major BPMS tools provide a significant amount of diagramming and 
definition flexibility. This is both a strength and a weakness. Because models can be 
built using any of the available symbols, the use of the symbols must be 
standardized for the models to be readable. This is true even using a tool that has 
been built to follow the BPMN standard set. 

It is also important that in the BPMS tools setup you consider the symbol sets that 
will be used and whether special symbols are needed. This use-design will likely 
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need to follow the Business Process Modeling Notation standards (BPMN), since 
most BPMS tools follow this standard. However, as noted earlier, in some BPMS 
tools there is minor flexibility in defining symbols and data-capture screens. 

Note: BPMN is a set of graphical standards that specify the symbol sets that will be 
used in BPM diagrams/models. /Is such, they define the symbols that will be used in 
depicting process and workflow in business modeling. The BPMN standards were 
originally formed by the Business Process Management Initiative (BPMI) and are now 
maintained by the Object Management Group. In addition to symbol standardization, 
BPMN attempts to standardize terminology and modeling technique. 

Most process modelers offer a drag-and-drop form of use that allows a user to select 
a symbol or connector from a menu and then drop it where he or she wants it. If 
swim lanes are used, the context of the setup must first be defined. 

Note: Swim-lane models divide a screen or page into multiple parallel lines or lanes. 
Each of these lanes is defined as a specific department or by a role that a person plays 
in performing the work. The work moves from activity to activity, following the path of 
the flow from business unit to business unit or from role to role. The way these models 
are set up for each project must be controlled by corporate standards if the long-term 
vision is to build an integrated corporate business model. These standards should 
govern when and how the swim lanes are defined (business unit or role), how the 
activities are decomposed, what data is collected in the modeling, and more. 

The same is true for the information that is captured. It must be defined and 
standardized in the BPMS for consistent use. Setting these standards and controlling 
their use should be the objective of a company's BPM Center of Excellence, or a 
company Business Transformation group. If these do not exist in the company, a 
cross-functional team of members from the business, IT, Business Architecture, Data 
Management and BPM should be formed. If this is required, it is important to make 
certain that all groups are represented and that all agree to follow the standards and 
rules that are created. Without this input, the standards will be imposed without 
broad acceptance or an understanding of their purpose or value and they will not be 
well accepted or used. 

This section talks about the major components of a BPMS and forms a composite 
picture of the more important capabilities of this environment. It should also be 
noted, that although each vendor approaches this in a different way, all tool suites 
provide basically the same capabilities and function in much the same way. 

10.3.4.2 Application Generation 

Most legacy applications are oriented to supporting work. They are used to handle 
repetitive tasks against large numbers of transactions. 

Today, BPM allows you to not only consider transaction applications, but also work 
management applications — applications that control the flow of work and how that 
work is done or should be done. This includes workload assignment, workload 
tracking, workload balancing, workload aging, error identification, performance 
management, reporting and more. 
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Application generation involves the use of business models to provide context and 
direction to the workflow, and rules to identify the data that will be used and the 
action that will be taken. Forms that are defined in the BPMS tools generate the 
screens that are used. This is a form of Object Oriented Programming, in which 
different objects are defined by a combination of activity and rules, and the 
execution sequence is defined by the placement of the activity in relation to other 
activities in the workflow. Because the applications can be generated every time 
they are used, any change to the workflow models, the rules, or the forms will be 
immediately included in the application. 

Application generation creates a different type of application than those created in 
the past using traditional computer languages. These applications are made of small 
independent modules that execute when called. Each activity in the process map can 
have any number of associated rules. The process map’s activities provide context, 
sequencing, and relationship. The associated business and technology rules provide 
the commands — call, perform, etc. Each activity essentially calls the rules, and at a 
lower level of detail, the rules can call other rules and data. Control over the human 
interaction is defined in forms that tell the BPMS how to build screens and then, 
using associated rules, tell the suite what to do with the data. 

The development of user-friendly BPMS forms is critical to the acceptance of the 
new business design by the users. These forms define User Interfaces (often 
referred to as Graphical User Interfaces or GUIs) and represent a fairly time- 
consuming and cost-relevant element of any BPMS implementation project. This is 
the part of the overall redesign that the user will see and work with daily. It is 
critical that this design be laid out with the user and modified through simulation or 
iteration to provide optimal ease of use. It is also important in this design to get data 
element definitions right and to find the accepted source for each data element on 
each screen or form. Business logic and data use/edit rules are also associated with 
each data element and each form. These components, when viewed together, 
represent the way the system will be used and determine whether it will be "user 
friendly." 

The finished application is really a series of reusable modules that call data or do 
something with it. These modules are like pearls on a necklace. They can be strung 
together in an infinite variety, where each does one thing and then passes the 
results to another module for the next step. Because the modules (activity level or 
lower steps and rules) are independent, they can be used in a variety of applications. 

This application generation is the major breakthrough in BPMS. This is the tool, 
when used with a modeler and a rules engine, which provides speed of change. 
Application generation allows IT and business to change the way they approach 
automated support. Through this tool, business and IT will eventually become 
merged for application development, maintenance, and enhancement. Process 
Models and Rules Models, together with the definition of screen and other forms in 
the BPMS, provide the specifications needed to generate applications. The program 
modules and the way they are executed by the BPMS allow a totally different 
approach to business and to IT. In the not-too-distant future, legacy and purchased 
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applications will become anachronisms as they are replaced by generated 
applications made of BPMS modules. While this is still a future possibility, it is not 
science fiction and it is coming soon. As this nears, the ability to change will become 
a core competency in companies, and those who move to adopt this new model will 
have a significant competitive advantage over those who are late adopters. 

Today, many of the better BPMS tools support very flexible and rapid application 
generation and modification. They also support high transaction-volume activity 
and complex logic. Using external database tools, the BPMS-generated applications 
can also support high-volume data use and storage. Because of this flexibility, some 
application vendors have begun to use a BPMS engine in their software products. An 
example of this is the healthcare package called Soarian by Siemens, which is built 
using the TIBCO BPMS. 

10.3.4.3 Supporting Groupware and Collaboration 

While most vendors excel at providing some of the functionality shown in Figure 67, 
many are either weak in some areas or do not provide a full suite of tools. As can be 
expected, due to competition a growing number of vendors are now reaching fairly 
high levels of support across all areas of functionality. 

This functionality, for the most part, works and actually performs well for all the 
major vendors. A key feature of the major BPMSs is the ability to support large 
numbers of concurrent developers and users and to hand models back and forth 
between people or teams. This ability allows the tools to be referred to as 
"groupware." It is this ability that lets BPMS-supported applications be modeled in 
one location (by one or more teams), constructed by BPMS Developers and Data 
Architects in a second or third location, and then used in multiple locations. This 
ability also allows distributed teams to work with the same sets of models and the 
same information. Of course, governance in this open environment becomes critical, 
but the key is that all parties must be governed by the same set of standards and 
that each group’s work be periodically audited for compliance and quality. In this 
way, the teams can work together to evolve designs or add detail. When this 
happens, the BPM environment’s data repositories can easily begin to evolve into 
true enterprise management repositories. Because of this groupware capability, a 
great deal of the technical side of using a BPMS to build applications has been 
moved offshore in support of an approach called the Global Delivery Model. 

This opens the business environment to real collaboration between internal groups 
and with partners, as it supports the use of the tools by people in different locations. 

10.3.4.4 Rapid Evolution 

At present, it is suggested that the tools from the following vendors be reviewed as a 
starting point in any look at functionality. This list is partial and is meant only as a 
start in looking at full BPMSs. Although these products are considered to be among 
the leaders today, this list will change as the leaders leapfrog one another and new 
companies release high quality tools. 

• IBM/Lombardi 

• Software AG 
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• Global 360 

• Oracle 

• Pega 

• Sawion (Progress Software) 

• TIBCO 

Note: The vendors are placed on this list alphabetically. Placement does not indicate 
quality, completeness or preference. It is recommended that the Forrester Wave or the 
Gartner Magic Quadrant BPMS rating reports be used to identify the leading vendors 
at the time you are interested in evaluating BPMS tools. 

The result of this leapfrogging one another is a rapid evolution in the BPMS tools 
and the advent of a set of tools that can handle large transaction volumes, large 
databases, and complex logic. However, because the main tool suites do vary in 
capability, it is suggested that any consideration of moving to a BPMS tool or 
consolidating BPMS tools to a single enterprise-wide BPMS, begin by defining the 
business and technical capabilities that are required, and then go one major step 
further to define the way the tool will be used, and by whom. This adds an "ease of 
use" dimension to any tool evaluation or selection. Excellent places to begin this 
research are groups like Gartner, Inc., Forrester Research, and IBM Research. Other 
good places to look for information are the Business Process Management Institute’s 
website (BPMI), the ABPMP website, and the Bruce Silver.com blog. In addition, 
social networking sites like Linkedln offer access to different BPM groups and thus 
access to a variety of experiences and ideas. However, information from social 
networking sources must be considered to be suspect because anyone can claim to 
be an expert. 

10.3.5 Business Activity Monitoring (BAM) 

Performance Monitoring, Performance Measurement, Performance Reporting 

The objective of BAM is to provide a comprehensive look at the business operation 
as the operation is performing its tasks. This allows management to take corrective 
action as problems are occurring and helps optimize the performance of the 
business. 

Although usually included in the BPMS tool suite, Business Activity Monitoring is 
not supported equally by all the BPMS. Most BPMS tools have a basic level of BAM 
built into them. However, this is a basic level and advanced reporting is supported 
by only a few BPMSs; most vendors rely on external tools that are fed by the BPMS 
as its applications are executed during business use. 

Generally, BAM is considered real-time, online monitoring and measurement of 
activity that will feed various performance review programs. Data is aggregated and 
compared against KPIs and other standards to determine quality and perform work 
management, such as workload balancing with case assignment or shifting. Six 
Sigma performance applications can be used in-stream to monitor workflow against 
preset evaluation limits and feed back into the BAM for near-real-time reporting. 
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An exception to this real-time use is the addition of performance (completion etc.) 
information from the execution of legacy applications and application execution 
data. Here the information from the BPMS and other performance monitors are 
collected and added to information from legacy application execution and external 
sources to form the data used in a broader analysis of the business operation’s 
status. This information can be fed to databases outside the BPMS for use by a 
variety of Business Intelligence tools. 

10.3.6 Enterprise Application Integration (EAI) 

Communication Templates, Accelerators, Adaptors used to access legacy application 
data 

Enterprise Application Integration (EAI) helps implement the SOA protocol and 
vision. It is supported by tools that enable the creation of "adaptors” between the 
communication medium (ESB or other communications platform) and the 
applications themselves, as well as between applications. An application may have 
one or more adaptors, depending on the way data are to be obtained and used. 
These adaptors control the translation of data from to and from the format used in a 
given application, and its flow to and from the communications platform. 

In practice, an application’s data is opened or exposed to access by a call to the 
program over the adaptor. The adaptor takes the information from the target 
applications and puts it into an SOA-based format for generalized consumption by 
other applications that have adaptors to control the translation of data to and from 
the application. This greatly decreases the number of interfaces between 
applications and between programs within applications. It also decreases the 
complexity of interfacing applications and reduces risk and cost. Again, however, 
data integrity is a key issue that must be addressed. 

The process of building EAI adaptors to legacy applications is called Wrapping. 
These adaptors are custom-built to deliver or obtain information from applications 
or to access certain parts of the application’s functionality. 

10.3.7 SOA 

This part of the SOA discussion provides a more technical view. This discussion has 
been provided by Michael Fuller, a former Managing Principal who is currently an 
independent consultant. 

10.3.7.1 What is SOA? 

Service Oriented Architecture (SOA) is a flexible set of design principles used in 
application systems development and integration. The applications are written as 
individual services that follow SOA-formatted calls to data in legacy or other 
applications. These calls are passed to Enterprise Application Integration (EAI) 
adaptors and translated to calls or update (puts) in more traditional programming 
languages that operate within the applications’ technical environment. This allows 
data calls and puts to be built following a single SOA format and then delivered 
(often using an Enterprise Service Bus or ESB) to an application in a way that it can 
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easily accept without the need for complex interfacing. However, this is still not a 
simple process, and although SOA, EAI, and ESB-use does simplify the need to get, 
move, deliver and format data, it still remains a complex task. 

This provides a loosely integrated group of program modules that can be used on an 
as-called basis. In addition to creating this type of object/service library, SOA 
provides a format and foundation to notify consumers of these services of their 
availability. 

10.3.7.2 How Does SOA work? A background. 

SOA is an approach for linking resources to obtain or present data "on demand." 
Within the Service Oriented Architecture (SOA) paradigm, there are two 
fundamental and independent resources: Interface and Implementation. 

The following definitions are important to the discussion of a Service Oriented 
Architecture. Because of their nature, the definitions contain technical references 
that the business-oriented BPM professional may need in discussions with the IT 
SOA architects. 


Interface: The software that calls data from, or presents data 
to, one or more applications that are external to the 
application being executed. The interface address information 
for locating the associated implementation^ ) is called the 
request. 


The request is the command that begins the execution of the interface and calls data 
from, or inputs data to, a database through the system being accessed. Once the data 
call is executed, the data is presented to the "interface" program with the content of 
the WSDL (see below) used to "direct" the request to the program that is invoking 
the service or interface. This program is called the "implementation." 


Implementation: A program to invoke a service, but does not 
contain “business logic." 

WSDL: The Weh Services Description Language (WSDL) is a 
standard way for defining a service interface. 


The basic elements of WSDL are: 

• Interface information describing all publicly available services (functions) 

• Data type information for all message requests and message responses 

• Binding information about the transport protocol to be used (e.g. tcp/ip, http, 
jms, etc. A single service can be supported over multiple transport protocols). 
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Service: a service is a specific executable or program that is 
defined by the set of functions it supports. Services are 
independent program modules that can be called by other 
programs or services and executed to provide a specific action 
or product — function. 


10.3.7.3 SOA Principles 

SOA is a data access and delivery strategy pursued by the enterprise — it is not 
simply a tactic or technique that the enterprise adopts to pursue a goal of improved 
application interfacing. The distinction is critical. Because of the scope of change and 
the impact, a move to SOA should be closely associated with the strategic goals, 
objectives, and benefits sought by the Enterprise Architecture. 

Today, there is no single consensus on what the term SOA entails or how to 
distinguish between an "SOA Solution" and a "Non-SOA Solution." SOA can be 
viewed within the framework of accepted principles that can be applied to evaluate 
the use of an approach that delivers SOA’s principles. Although there is debate on 
what SOA entails, as part of defining accepted principles there is general consensus 
on the benefits of SOA: "flexibility," "agility," "scalability,” "reuse," etc. In addition to 
these significant benefits, SOA mandates provide a benefit that has been elusive — 
the deconstruction of the barriers that typically exist between the "business" and 
"I/T"; between different "business units"; and between different "I/T specialties." 

To help control the use of SOA, the industry has accepted a large number of 
international standards that most vendors, consultants, and the media associate 
with SOA. The main standard is the "Extensible Markup Language" (XML) published 
by the World Wide Web Consortium (W3C). XML is a standard for defining a 
"vocabulary" that describes information being moved among systems. XML allows 
programmers to describe the "syntax” of the information, but not the "structure” or 
"semantics" of the information. The XML Schema standard, also published by the 
W3C, provides the "vocabulary" for describing the "structure" and "semantics" of the 
XML document. 

Note: the term " XML document" refers to anything that is encoded using an XML 
vocabulary: a business letter; a purchase order; a message exchanged between parties; 
a schema describing a database; etc. 

Overall, there are more than 30 additional standards published by the W3C, OASIS 
(Organization for the Advancement of Structured Information Standards), the ISO 
(International Standards Organization), the OMG (Object Management Group), and 
others that are closely associated with SOA. Among these are the Web Services 
Description Language (WSDL), WS-Policy, WS-Security, WS-Reliable Messaging, 
Business Process Execution Language (BPEL), Business Process Modeling Notation 
(BPMN), Java Script Object Notation (JSON) and many others. 
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The standards used by a particular enterprise in creating their SOA solutions, and in 
particular what portions of the complete standard are used, determine how SOA will 
be used and which of the many SOA benefits a particular enterprise is emphasizing. 
SOA is thus not a one-size-fits-all for company IT environments or business use 
strategies. 

To implement SOA it is thus necessary to define its goals, use, and internal 
standards. In creating an SOA strategy, it is important to identify the benefits that 
are needed and then adopt the standards, methods, techniques and concepts needed 
to deliver these benefits. It is also necessary to make certain that IT and the business 
have a clear roadmap for how an SOA strategy will be implemented and what role 
the people involved will play. But, even with a clear vision, a strategy and a plan, the 
management of the implementation will require funding and constant oversight to 
ensure that the new approach is being followed the right way. 

SOA requires that a company consider and explicitly document what "resources will 
be linked on demand” — for example, processes, messages, data entities/views, data 
stores, rules, events, etc. 

It also requires the company to consider and explicitly document 

• Whether the "resources linked on demand" are always internal to the 
organization or may involve their business partners and customers 

• How changes will be controlled 

• Work in migrating their software environment to an SOA format 

• The ability of their technology platform to support SOA changes 

• New data storage requirements. 

SOA by its very definition — "A system for linking resources on demand” — requires 
that companies understand how it can be used so they can manage the costs and 
risks inherent in this approach. Because of its flexibility and the way it opens data 
access, it is critical that a comprehensive and effective governance regime be 
implemented. The lack of comprehensive and effective governance is the most 
commonly cited reason for the failure of SOA initiatives. 

A major governance challenge for SOA is managing the lifecycle of services from 
conception through specification, development, testing, deployment, daily 
operations, and finally retirement of the service. This includes controlling changes 
to the ways 

• Organizational units collaborate 

• Decision rights and responsibilities are handled 

• Process is changed 

• Procedures are vetted 

• Methods and techniques are used. 

There are currently a great many software products that are closely associated with 
SOA, including Service Registry, Service Repository, Enterprise Service Bus, Complex 
Event Processing, Business Process Management System, etc. Companies of all sizes 
have succeeded in their efforts to realize the benefits of SOA. But many companies 
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have also failed. These products can provide a standard platform to build an 
enterprise’s SOA solutions, but unless the enterprise has systematically 
institutionalized the requisite strategy, methods, standards, governance regime, 
techniques, and staff development programs, the products will simply not deliver 
the expected benefits. It is therefore important that these be put in place as soon as 
possible in any organization that is seriously looking at moving to SOA, expanding a 
limited used of SOA, or having trouble implementing SOA. 

10.3.7.4 Moving to SOA 

The following must be considered when moving to SOA architecture: 

• Vision, strategic planning, executive acceptance and budget assignment along 
with expectation management 

• Business performance evaluation strategy — value, line-of-sight from 
Strategic goals through run-time performance of a service, or composite 
application techniques for realizing both the benefits of SOA 

• SOA readiness assessment — current technical environment and architecture 

• Definition of SOA strategy — including use definition and implementation 
roadmap 

• Definition SOA architecture — that considers things such as, operating with or 
without an "enterprise service bus," static vs. dynamic instantiation of 
services, static vs. dynamic binding of service policies, enforcement of 
SLAs/QoS, realization of operability goals such as availability, reliability, 
fault-tolerance, etc., and use of a repository/registry to support the service 
life-cycle) 

• Governance — full life cycle including SOAP rules and how they will be used 
(see SOAP below) 

• Identification of initial services to be used in prototyping and the 
requirements of the prototype — including results reporting and analysis 

• Definition of service types that will be built 

• Build an SOA capability — Training and Proficiency Testing, tool selection and 
implementation 

• How to develop, test (coding/code debugging), and implement SOA 
access/interfaces/EAI adaptors, etc. 

• How to define, design, build and implement an ESB — including any redesign 
of current communications. 

Note: While these activities are key considerations, this is not a comprehensive list. 

10.3.7.5 SOA and SOAP 

Embedded within the SOA umbrella is a set of standards that govern data transfer. 
These standards, named Simple Object Access Protocol (SOAP), are a set of rules for 
transferring structured information across a network in the implementation of Web 
Services. SOAP messages rely on the use of Extensible Markup Language (XML) as a 
message format. 

SOAP rules can be organized into three groups: 
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1. A message packet — defining a message format and how it is to be processed 

2. Coding rules for defining SOA programming along with data format and 
content 

3. Standards defining program procedure calls and responses. 

Following these rules, programmers build code modules that operate as individual 
small programs. Each performs an action and then passes the result. By calling the 
modules that you need from a module or service library, the programmer has 
flexibility in the use of the services and the ability to reuse them either as they are or 
with modification. This allows programs to be constructed from common parts and 
reduces the programming time and risk. 

SOAP characteristics include: 

• A protocol for defining and building programs to allow and govern 
communication between applications over the Web or over an internal ESB 

Note: As a protocol, SOAP is platform and computer language independent. 

• An ability to deal with internet communication 

• Adheres to World Wide Web Consortium (W3C) standards 

• Support of text, voice, email. 

10.3.7.6 Using SOA 

To define the way to integrate different legacy and/or new applications for use by 
multiple separate business units or applications, SOA defines interfaces in terms of 
protocols and functionality. This allows the interfacing to be standardized and 
allows systems to share data with others that follow the same protocols. This 
reduces the point-to-point interfacing between applications used in the past and 
simplifies the way applications can share data. This also, however, increases the 
criticality of data integrity for the data in use. 

By using standardized services (program code modules or objects) and 
standardized interfacing, SOA offers new ways to build service oriented applications 
that are external to BPMS-generated and legacy applications. However, the 
applications generated in in the BPMS-supported BPM environment follow a 
standardized format and are conceptually similar to SOA-oriented program code 
modules — they perform one function, they are standardized, and they are reusable 
program objects. 

Applications following a SOA approach and used to support BPM may include 

• Workflow execution — leverage SOA concepts to create programs and obtain 
data needed to perform activities 

• EAI services — adaptors supporting SOA communications approaches 

• Business Intelligence — operational statistics, audit etc. 

• Rules management — description and execution capabilities 

• Process operation — action or work monitoring and control 

• Performance management — obtain data from the real time BPM applications 
and from legacy and other applications following SOA protocols. 
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10.3.8 Enterprise Service Bus (ESB) 

An Enterprise Service Bus is a software architecture, set of software tools, software, 
and a communication medium or carrier. Together these ESB components control 
the movement of data between computers. Applications in an ESB-supported IT 
architecture can communicate by tying into the communications carrier (network) 
part of the ESB, which serves as a message broker between the various applications 
in the company that use the ESB. Each computer on the ESB is a separate node on 
the network. Each has a separate unique address on the network. The applications 
using the ESB will define the places or nodes that will receive the message or 
request and then assign the right address or addresses to the message. All nodes on 
the network constantly monitor or listen to the traffic on the network, waiting for a 
message with their address. When heard, the node accepts the message and sends it 
through the EAI adaptor to the application. The adaptor converts the format of the 
message so it can be accepted by the application. The reverse is true for messages 
being sent by an application. 

The ESB software tools thus sit between the applications and work with the 
Enterprise Application Interface (EAI) software, allowing legacy or any other 
applications to communicate over the ESB in a standard format. 

When used with an SOA open-messaging approach, information can be broadcast 
over the network for all applications on the ESB to hear and use. These messages 
will be in a common SOA form so they can be easily consumed by the EAI adaptor. In 
this way, information can be easily sent to several applications at one time, without 
a need to build separate interface programs between each of the applications. This 
eliminates the need for much of the point-to-point or application-to-application 
communication connections (interfaces) that exist today. 

This simplification of interfaces and the reduction in the number of interfaces 
between applications reduces the risk of change, cost of change, and the time it 
takes for a change to an application. 

Enterprise Service Buses normally work well with BPMSs and are, in fact, part of 
some BPMSs such as the IBM WebSphere and TIBCO suites. 

10.3.9 External BPM Enterprise Transaction Data Repository 

BPMS repositories have the ability to store a majority of the information on the 
company’s operation. They do not, however, usually store all the value data that is 
collected from transactions that are processed through the BPMS-supported 
business operation. Because of the volume of this information, these transaction 
values are often externally stored using DBM tools. The key in determining what is 
stored within the BPMS repository and what is stored externally is often use-based. 
For example, the information needed to drive the business operation, such as task 
assignment, work routing, and screen content is generally stored in the tool suite 
database. However, in any BPMS or BPM tool implementation, the internal Data 
Base Management group should be involved determining what will be stored where, 
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creating the data schemas that will be used, and determining 
applications/databases that will service as "sources of record" for given data. 

Process repository content can include the following for Process and workflow 
models. 

Note: Process is cross organizational and cross functional in nature. Workflow is at an 
organization or function level and looks at the activity that is performed in the 
organization to produce a product or sub component. 

• Who owns the process 

• What the process does 

• What activities are taking place and their links to one another 

• What technology enablers and controls are used 

• What triggers or events initiate the process 

• What are the expected results 

• What problems are associated with each activity 

• When is the process initiated 

• Where the process take place 

• How the process interacts or links to other processes 

• How the process interacts with those of other business units or external 
enterprises 

• Volumes and timing 

• How the results are delivered 

• Why it’s needed, how the process aligns to strategic goals 

• Service Level Agreements, KPIs, goals, etc. 

• Process metrics such as time to perform, number of resources required, 
minimum and maximum concurrent executions, direct and indirect cost, etc. 

• Business Rules 

• Type and source of data related to the process 

• Regulatory requirements 

• Timing, nature and forms of possible output 

• Outputs that become a trigger for another process. 

This list will, of course, vary by vendor, but the higher-end vendors will have much 
of this capability. The key, however, is to make certain that the use of the tool suite 
is defined for both today and tomorrow when looking at a BPMS or BPM tool. This is 
necessary to provide the flexibility you need without having to completely start over 
or move to a more flexible tool suite as your needs change. Part of defining what the 
tool suite must provide is the definition of what information you believe will be 
needed to control the evolution of the operation, the ability to deal with legacy 
applications, and the flexibility you will need to keep pace with the changing 
business world. 

Because the repository can support collaborative business solution development, 
people’s ability to access it from multiple concurrent locations provides an access 
problem. Controlling access thus becomes an issue that must be addressed. While 
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this is really not a concern for most past uses of BPMSs for specific problem 
resolution solutions, it becomes critical in a broader use of these tools to create 
operating environments. For this reason, it is important for your Data Base 
Architects and Data Base Administrators to play a role in the selection of the right 
tool suite for your needs and for the way that the BPMS Enterprise Repository will 
be set up. 

10.4 Making BPM technologies work for you 

Success in any move to new technology depends upon an ability to understand the 
true capabilities and use of the tool, and an ability to work closely with the vendor 
you have chosen. This latter need may, however, require a negotiated relationship 
with KPIs imbedded in the license contract. In addition, it is important to consider 
how the tool and BPM will be used and to create a design or architecture of the way 
the tool will fit into your company's business operation and IT environment. It is 
also important to consider how data will be managed and how the tool will be used 
to support collaboration within the company and with partners. 

Note: This is not an all-inclusive or exhaustive discussion. It simply covers some of 
more important considerations that should be highlighted in any BPMS or BPM tool 
strategy. 

10.4.1 BPM Infrastructure Architecture 

An architecture is simply a design. A BPM architecture is a design of how the various 
component parts of a BPM environment fit together. Today, there are a great many 
of these architectures available for a BPMS-supported BPM environment. As with 
most things, some are better than others and some will more closely fit your 
company and how it thinks BPM and a BPMS should work within its operation. BPM 
is often started without any tool use in mind: it evolves and a tool is selected to meet 
business needs. This is normal and it is fine, but the tool selection (based on the 
vision for how the tool will fit into the company, how it will change the way business 
is approached and the way information is delivered) has a definite impact on IT and 
the business. This impact can be described in a design or architecture of the future 
operating environment. This is important because it is a guide for how the new 
business/IT environment will work and who is responsible for what. 
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Figure 69. Basic BPM Technology Architecture (Source: Reference Architecture for a BPM Infrastructure; 

Richard Watson, Research Director, Gartner) 

When all the component BPMS modules and concepts are put together, the model 
looks something like the one above. 

In this architecture, the BPM Enterprise Repository holds all the models, rules, and 
associated information about the company’s operation. This information is collected 
during the business analysis and modified in the business redesign using the BPMS. 
Once the new design is approved and the new business operation and applications 
are deployed, this information is used by the BPMS to support the execution of the 
business’s tasks. In a BPMS-supported BPM environment, this usually happens 
through the use of the applications generated by the BPMS. These applications and 
the business operation leverage links to data, using Application Program Interfaces 
in the EAI products to create legacy application adaptors. Calls for data will then go 
either over the ESB or directly to the source database. Of course, the security that is 
agreed upon in the IT Governance or Policy committee will control access to this 
data. The calls for data will then go through the EAI adaptor that controls access to 
the application or database. This creates SOA-based data packets that are then sent 
to the ESB for delivery. 
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Modern BPMS System architectures typically implement two different layers, a 
presentation layer (usually implemented in form of a web server with suitable task 
services) and a process layer, where the process engine executes process models. 
This will include web services that need to be defined or built (programmed) and, 
within the BPMS, the calls to execute external code modules. 

Although most BPMSs have fairly consistent architectural components, each is 
somewhat unique in the way it functions, the way it interacts with rules, the number 
of templates it provides to define web services (and more), and the way it accesses 
and uses databases. It is thus important to define the architecture that will be used 
by the BPMS you license and the way it will be used in your IT environment. 

10.4.2 Business and Data Requirements Definition 

As always, the business requirements that are defined in the business case created 
for project-funding approval will serve as the guide in setting project goals and in 
defining the project’s scope. Smaller projects that do not have business cases will 
still have a set of goals that can serve as requirements. These project-level 
requirements will continue to be used as the basis for determining project 
estimates, schedules, and completion-measurement steps, so real benefit can be 
calculated and compared to estimate. 

As mentioned above, the traditional approach to defining applications and business 
requirements begins with the creation of separate business and technical change 
requirements from a new conceptual design of the business. The conceptual design 
will itself reflect the project change requirements. In a BPMS-supported BPM 
operating environment, the delivery of these requirements can be tested in 
simulation. In a traditional approach, the system and actual business operation 
change-requirements definition begins with identification of the differences 
between the old and new business model. It then relies on business and technical 
people to convert these requirements into system specifications (specs) so 
programs can be built, test plans created, and training programs written. 

With the use of a BPMS, this traditional approach is becoming an anachronism. In 
the BPMS environment, the new business design, along with the rules definition and 
forms (screens) designs, becomes the new operation and systems requirements and 
specs. BPMS applications are generated from these models, making the models and 
the requirements definition the same thing. 

The delta from the old version of the business operation (the "As Is" models) to the 
new design ("To Be" models) defines the change and provides the specs for the parts 
of the change that are not addressed in the BPMS-generated applications. These 
specs focus outside the BPMS environment to look at a need for data acquisition, 
movement, and delivery, with legacy functionality use, web services requirements, 
and database design requirements. 

In the BPMS operating environment, the BPMS and enterprise BPMS repository 
provide the information and tools to model the business and then quickly define and 
design changes. These changes can be run through the simulation engines in many 


405 


Copyright ABPMP International 


Chapter 10. BPM Technology 


of the higher-end tool suites, and the results compared and analyzed, to quickly 
create new iterations that constantly improve the business operation. The new 
design from this iterative improvement process becomes the new baseline. Then the 
process of changing the business operation and its applications support starts again, 
in a never-ending cycle of improvement. 

10.4.3 Team Collaboration 

In a BPMS-supported BPM environment the business designs thus become the 
requirements and the rules become the logic that defines the requirements. This 
forces a new type of collaboration between IT and the business, redefining the roles 
that each group plays in the ongoing evolution of the operation and its applications. 
Fortunately, the groupware capabilities of the BPMSs allow multiple people from 
any location or locations to work together on the same business models. This 
creates a virtual team of people from multiple locations: the experts can be in any 
part of the business and still be involved in the creation, modification, and approval 
of the new business designs. This also allows them to be involved in the definition 
and approval of the rules, the way performance will be measured, and the way the 
operation will change and improve. 

Of course standards, control, and governance direct how this is done, but everyone 
on the team will always be looking at the same models with the same information. 
This is a critical improvement over the traditional business and applications design 
approaches. Using a BPMS’s collaborative capabilities, anyone and everyone who 
will be impacted can now easily have a role in determining how the business 
operation will work. This creates a very different dynamic. With this ability, it is 
now economically possible to ensure that any change is done with the people who 
will be affected and not just to them. 

The presentation of the business information is also much easier to absorb and 
comprehend than the traditional lists and text approach. Today, models and 
supporting data can be quickly referenced at a variety of levels of detail, and any 
audience or group can deal with the level of detail that they need — with the ability 
to move to more detail if they need to. This greatly improves the willingness of 
people to become involved and significantly reduces the time-requirement for most 
people on the process-improvement or problem-resolution project. 

These capabilities, however, require different consideration of issues that may be 
new to many people in the companies. The politics change, the need for inclusion 
changes, the applications that are supporting the business may be different, 
localized regulations will need to be considered. If you will need international access 
by teams in different countries, you will need 24/7 access and you will need to 
identify and understand the laws in each of the countries you are dealing with. 
However, if the company intends to offer its products in different markets, these 
issues will need to be addressed anyway. The BPMS tools simply allow this 
information to be collected and then provided at any time it is needed. BPMS thus 
becomes an enabler for the business to expand its brands. 
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10.4.4 Underutilized Capabilities 

The key problem in the past has been the approach to using BPMSs. A BPMS has 
seldom been considered as an operating environment and it has seldom been 
considered as an architecture. Most organizations have used BPMSs to help solve 
specific problems, and the use of these tools has been limited. There are usually no 
overall BPMS use guidelines and seldom an enterprise BPMS policy. 

This is because BPMSs have been viewed as tools, and their potential has been 
undersold by the vendors, who simply want quick sales. When used the right way, 
however, the BPMSs have delivered significant results. The suites are much more 
than most envision them to be. They provide a new way of delivering automated 
support and of approaching business evolution. When considered in the broader 
context (not simply as a problem-specific solution enabler) they have the potential 
to deliver unexpected results in the delivery of a continuous improvement 
capability, the environment needed to deliver a meaningful Six Sigma program, and 
the ability to optimize a business operation. 

This broader vision of the use of these tools provides a very different framework for 
looking at BPMSs and what a company expects from its investment. Unfortunately, 
few of the vendors today offer this vision, and the discussion on what a BPMS can 
really do is just beginning. However, the ability of the better tool suites to support 
this operating vision is available and the discussions on how BPM can really help a 
business improve are happening in organizations like ABPMP. 

10.4.5 Decision Support and Performance Management 

Among the generally underutilized capabilities in many BPMS-supported solutions 
is performance management and decision support. BPMS-supported operating 
environments offer a variety of performance management (performance 
monitoring, performance measurement and business intelligence) capabilities. 
These tools can also work with Six Sigma and other measurement tools to integrate 
their information into the data mix available for analysis and management activities. 

The use of these capabilities, driven by simulation of the solution that will be built, 
provides the foundation for actually measuring improvement related to the new 
solution. This will allow real ROI determination. Today, business cases are used to 
help justify the need for a project or action. But there is seldom a reasonable way to 
actually measure improvement. Once a business operation is being supported in a 
BPMS environment, this type of measurement is fairly straightforward and allows 
the business and IT to determine actual improvement, instead of just estimated 
improvement. This ability is a key part of the delivery of continuous improvement 
by BPMS technology environments. 

In these environments, the BPMS will support the redesign of the business and 
application components needed to make a change, and then predict the 
improvement through the simulation module. This can then be implemented and 
the actual improvement measured against the predicted improvement. This then 
helps guide further improvement, which follows the same process. When looked at 
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over any time period, it is thus possible to see the KPIs and other performance 
numbers at the start of the time period and then at the end of it. This is a way to 
measure actual improvement, and it can be applied at any level in the business 
operation. 

For example, if you implement a workflow in a BPM environment, you will be able to 
determine how any service in a Service Level Agreement (SLA) is measured. The same 
is true of a Key Performance Indicator ( KP1 ). Implementing these measurements can 
be easily accomplished within the BPMS technology environment or, using more 
traditional means, outside the BPM environment. By taking periodic readings, you can 
look at trends and determine improvement. At any time, it is therefore possible to 
determine improvement over a given period. By taking these updates following 
projects, it is possible to see the benefit of the project. 

In addition, BPM technology environments support work-in-progress monitoring to 
help balance and manage workload on any time basis — weekly, daily, hourly, etc. 
This is supported by real-time monitoring and dashboard reporting. Various limits 
can be set as rules and associated with activity or any level of work in the operation. 
The rules then drive the monitoring and measurement. This allows real-time 
intervention by management to keep the work flowing at an optimal rate. 

By adding standards and rules that look for patterns in the data, it is possible to 
move this level of analysis and reporting to the Business Intelligence level. This is 
predictive modeling and reporting. Base on the way the values are building in the 
various components that are being monitored, it is also possible to create rules that 
recommend action. While these types of reporting require creativity and an in-depth 
understanding of the data and the processes, they can be supported by the better 
BPMSs. 

10.4.6 Buy-in and Monitoring 

Creating a sound performance-monitoring capability requires the buy-in from all 
who will use it. While obtaining this buy-in is not a technology concern, it is related 
to the technology’s ability to support monitoring and the collaboration needed to 
obtain feedback and build consensus. This is important in determining the way the 
business really works. While the single-purpose modeling tools, rules engines, etc. 
do not support performance monitoring very well, the BPMS technology of the full 
product suites do support this through their collaboration and measurement 
capabilities. 

Using these tools makes it possible for all involved to see how performance will be 
monitored, measured, and reported. It is also possible for everyone to see how the 
rules that drive this monitoring will calculate and what data they will use. While this 
can be done outside a BPMS environment, it can be easily accommodated in real 
time across multiple groups and locations within a BPMS environment. This 
capability is not theoretical, and can easily be supported within a BPMS technical 
environment. 
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10.4.7 Setup 

While modelers and most other "single purpose" BPM tools are flexible, it is 
important that considerable use analysis be done up front to avoid setup problems. 
While the vendor will have a list of considerations that you will need to make 
decisions on, it is advisable to look internally at such considerations as: "How will 
you use the BPM tool or tool suite?" and "What flexibility will you need?" This list of 
decisions should be formal and it should be reviewed by the business sponsors and 
managers, the IT infrastructure group, the Data Management group, and the 
applications support group. If your company has a BPM Center of Excellence or a 
Business Architecture Center of Excellence, they should also review this list of setup 
decisions for completeness and for their ability to support any answer that is given 
to a decision on the list. 

In addition to how the tool will be used, it is critical to consider the data that will be 
collected by the tool to support the business, the way the data schemas will work, 
and the way the tool will interact with external databases and tools such as Word 
and Excel, legacy applications, and purchased packages such as an ERP. 

The answers should look at both current and future needs. In this way, the setup 
will tie into the vision and strategy of the BPMS or BPM tool’s use. The data captured 
in these tools’ models can change easily and quickly, but the structure of the tool 
and many definitions that are set up at the time of installation cannot. To avoid 
limitations on how you can use the tools, it is important that they be set up for your 
use to optimize your capabilities and the way the functions work. It is suggested that 
care be used in approaching implementation issues with the vendor and that you 
have a clear understanding of what you need the tool suite to do, both now and in 
the future, before you begin implementation. 

While this sounds like a basic consideration, it is often narrowly focused and often 
fails to look at the long-term use of the products or the true business needs that 
must be addressed. This information should be reviewed in detail with the vendor, 
who should be able to provide guidance on how to optimize the internal tool setup 
during each installation. 

10.5 BPMS Governance 

Governance is a tradeoff between control and flexibility. The more control that is 
imposed, the less flexibility is available to the users, architects, and applications 
development people. In a BPMS-based environment, this need for control becomes 
greater than in the past. However, the strength of using a BPMS is the speed of 
change — implying minimum control. So, the two goals are opposed to one another. 
While this is an age-old problem, it now takes on a different spin. We can now do 
things that we could never do in the past, with the help of BPMS tools. For many 
things, the question now moves from "can we do something?" to "should we do it?" 

An example is a change to an operational management application generated by a 
BPM suite. We can now define the improvement, model it, simulate different 
options, and then implement the change in almost real time. This was seldom 
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possible in the past. But to do this, we need to suspend control. So, we can make and 
implement change very fast, but should we? The answer here is "no, we shouldn’t." 
We need some form of quality control prior to implementing any change. That is 
simply a wise policy. But how do we want to control the process? We could impose 
barriers that add weeks to the almost-instant process. That also is not wise. So, 
where do we draw the line? The answer will be different for different situations and 
for different companies. Whatever the company decides, this issue must be carefully 
debated and the appropriate compromise reached. 

This concern is reaching new heights as "cloud computing" and "cloud applications" 
are considered. The Internet is a wonderful tool and it is changing the world. But it 
is full of danger and many companies have experienced continuing breaches, data 
loss, and more. As the issue moves out of the IT department, it is necessary for the 
business managers and IT to work together to understand risk and spend the funds 
to implement the right level of security — in everyone’s opinion. The value of open 
access to Internet sites by customers is a game-changing requirement in many 
businesses. It cannot be underestimated. But too much control will impose barriers 
and limit the value of this channel. Similarly, too little control will expose the 
company to risk it doesn’t need. This is a constantly changing line that must be set 
with the full involvement of IT and the business officers in any company. The 
decisions that are made in this regard will have an impact on collaborative teaming 
and on the way BPMSs and applications are approached and used. These decisions 
are important in looking at both BPMS acquisition and setup. They are also 
important in looking at the need for flexibility and speed in responding to customer 
demands and market opportunities. 

10.5.1 BPM Standards and Methodologies 

Today, many companies have moved into point-specific BPMS solutions without 
standards or accepted methodologies. This is often made more complex by the 
politics associated with different business or IT groups getting involved with 
different vendors within the same department or company. In these companies, 
what may be best defined as a political "war" over whose BPMS technology will 
become the company standard can arise; everyone will have a lot invested and no 
one will want to absorb the cost or disruption of changing to a different BPMS and 
thus new applications. For this reason, it is important for a central BPM 
management group to form as quickly as possible. These groups are often called 
Centers of Excellence. However, wrestling with the politics of creating the initial 
BPMS environment is a challenge and will usually require executive leadership. 

Even so, it may be difficult for management to move to a single BPMS once multiple 
tools suites have been used in the operation. In short order, there can be too much 
disruption associated with the migration to a single vendor’s BPMS. In this case a 
multi-vendor BPM-tool strategy will need to be formed. 

Even in multi-BPMS-vendor environments, consistency can be obtained through the 
creation of standards on modeling, rule definition, vocabulary, naming, etc. Where a 
BPM Center of Excellence has been formed, its members usually become responsible 
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for defining and negotiating these standards and for enforcing them. As a result, the 
Center of Excellence must have the participation of key operational people so that 
these standards make sense in the context of the company’s business and culture. It 
is equally important that the standards are not a burden — if they are, they will not 
be followed. So, care must be taken in creating this control. 

However, it is premature to think that there is a set of accepted standards for BPMS 
use in the industry or in companies. BPM and its BPMS technology is still new and it 
will be up to groups like the ABPMP to create standards in different areas of BPMS 
capabilities and use. In the interim, it is necessary to move forward and create 
standards for the use of tools within your company and the modeling and other 
techniques you will use. This is important for information understanding and for 
use among the different internal groups. These standards should include 

• The information that will be collected and the way it will be used to set up 
the system 

• Model symbol set (usually this will follow BPMN standards) 

• Data repository 

• Access security and regulatory and legal requirements that may apply 

• Use architecture: all models from different projects should fit together to 
form an enterprise picture 

• Standard terms and levels, etc. 

• Governance. 

10.5.2 Governance Models 

As with many aspects of BPM, there is no shortage of information on the Internet 
about BPM governance. These discussions include use, setup, and control. It is 
advisable to view the majority of these articles and approaches with skepticism as 
you research them for ideas. Some are true and good, but others will not work and 
still others may be good ideas, but not a good fit. 

BPM Maturity is an example. Gartner, Forrester, IBM, and other groups have 
developed BPM maturity models to show the way companies move through a type 
of lifecycle to maturity. These models are often similar, but can have significant 
differences in areas such as governance. Some of these models look at only parts of 
the BPMS and BPM governance needs and focus on tool use; others are broader and 
have more detailed concerns. As noted above, the Internet is full of articles related 
to BPM and BPMS governance, and care must be taken in considering any papers or 
articles found on blogs, consulting firm web sites, Linkedln, and open forums. Some 
discussions are good and others simply prove the need for vetting information 
obtained from unknown sources. It is clearly necessary to look at as much high- 
quality information as possible in forming your governance model. It is also 
necessary to customize your governance to your company and the way it will use 
BPM and a BPMS tool. 

While the governance models and information you find can help in planning how the 
company will control the evolution of in its use of BPM, they are not a real guide and 
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should not be considered to be a roadmap. They are, however, a good place to find 
ideas and can be used to help define and plan changes in control as the company 
moves from level to level in the evolution that is shown in the BPM maturity model 
adopted by the company. 

The problem in setting up a governance process is that each company is unique and 
the path to a BPMS-operating environment will be different depending on many 
factors. These factors include the willingness of the business managers and IT 
managers to accept controls, the current operational culture and standards that are 
in place, the state of the IT environment, the nature of the company (collaborative or 
closed, local or multi-facility, US or international, etc.) and more. This fact in no way 
suggests that a formal governance model and plan are not needed. It does suggest 
that this is a serious part of your BPMS implementation and evolution; it must not 
only be put in place, but monitored and changed as your needs are better 
understood. 

10.5.3 Data Integrity 

"Garbage in, Gospel out." - Rod Moyer, VP, BenefitAIlies 

Even when everyone knows that the information in a system is suspect, they use it 
as if it were the final word. They actually have no choice. This is true in any internal 
activity or in any interaction with a customer. While the causes for poor data vary, it 
is frustrating to everyone dealing with a company and causes untold hard feelings 
with customers. But it is accepted within companies because data cleanup would 
break the bank in most companies. The real problem this causes is that management 
and staff do not know who to trust in customer interactions or what the information 
is really telling them. 

In addition, data security is a problem that is getting worse. Not only is data often 
lost, but it is often corrupted. Data corruption is the more serious problem because 
IT managers often do not know what is corrupted or when it was done, so no one 
can identify or fix it, and restoring it to an earlier point will cause untold loss of new 
data. From this perspective, the Internet and other technology advances have 
actually hurt companies, as well as customers, with the problems of viruses and 
information theft. In a Cloud environment, it will be much worse. In an environment 
where people can access anything with their mobile phones, the problem will go off 
the charts. 

Today, with the growing identity-theft problems and acknowledged problems with 
application interoperability, data redundancy, data quality, and data timeliness, the 
problems with data integrity are growing. Data-related errors cost time, money, and 
customer loyalty; they can even lead to legal problems. There is no silver bullet 
here: BPMS supports rapid application change to internal and customer-facing 
systems and exposes the customer to greater potential interaction with the 
company. Companies that have data quality problems will find that the increased 
interaction shines light on these weaknesses. 
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This is a quality issue, one that many companies have ignored for years. In moving 
to a BPMS operating environment, companies will once again have an opportunity 
to improve the foundation. While BPMS tools and techniques cannot fix old data 
quality problems, they do present an opportunity to tighten control over the new 
data and correct data errors when found during customer interaction. 

Because the generated applications in a BPMS-supported BPM environment are the 
primary places where data is collected, data edit rules and rules that control data 
use are critical. Both standards and corrective action in this area should be created 
by a composite group of Data Architects, Process Architects, Business Architects, IT 
security management and BPM implementation planners. As with all security and 
governance, this area represents a set of trade-offs. However, one of the most 
valuable assets of any company is its data. It is the lifeblood of the company, and its 
loss or corruption can be a game-end level problem. Its corruption is a serious issue 
and it must be considered in any move to a BPMS. Such a move presents the 
opportunity to improve the controls placed on checking data for quality and 
completeness. If done right, the BPMS rules can actually start helping improve the 
overall quality of the data even in legacy applications. 

So far, most uses of BPMS have been narrowly focused, so data integrity has been an 
isolated concern. But that is changing. As the use of BPM in any company increases, 
the issue takes on a new importance for the BPM architect and implementation 
planner. 

Today, some companies are trying to do something about it and are spending time 
and effort to go through the fragmented customer information and pulling it 
together while trying to clean it. Some companies are addressing this problem 
through the externalization of rules (outside of the legacy applications). Many are 
also involved in projects to identify and define business rules throughout the 
company or at least in large parts of their business. However, as these needed 
efforts are going on, it is imperative that the data-capture approaches be changed 
and that any BPM activity considers this need to improve data integrity. 

This requires a new emphasis on controlling data access, data use, and the way it is 
checked. It also requires that company-wide standards be put in place and that new 
data-collection policies be applied for every application and every data access. This 
can be accomplished at a company level much faster and for much less cost than 
other methods by using BPMS technology to create new front-end operational 
management capabilities. The control the company thinks is needed and the 
creation of data standards should be part of the rules that are put in place and the 
vision that will guide the acquisition and use of BPMSs. 

At some point in the future, when a company’s use of BPMS and rules has matured, 
it is recommended that they consider the value of creating stringent rules-based 
edits and running all legacy data through the BPMS-generated applications that 
support these edits. This will help clean data and improve quality. However, it will 
also require mining the current edit rules and then upgrading them. Such an effort 
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will take time and require thought to make it worthwhile; the eventual question for 
management is the value of better information. 

10.5.4 Evolving as Technical Standards Change 

As noted above, managing and integrating models to form a composite picture of the 
company and its processes requires a BPM tool and the careful building of business 
and technical standards. These standards will control the use of the company’s 
modeling tool or BPMS as well as the approach taken in incrementally tying project 
business models into a complete mosaic of the company. 

In order to be effective, these standards will need to be blended with current IT 
operational standards, database use standards, Business Architecture standards, 
and others. This will eliminate overlaps and disconnects and create a set of 
integrated standards for the company. This integration of standards, however, will 
be a future goal that the company will need to work toward. For this reason, the use 
of standards in any area will evolve and the retrofitting of standards will require 
some additional work. This will be necessary because many standards are already in 
place and their extension, reuse, modification or deletion will need to be negotiated 
by a group that includes representatives from the major players in the company. 

While this negotiation is going on, the BPMS users should move forward as quickly 
as possible to provide controls for consistency and repeatable success. These 
standards will be less specific in addressing business issues than technical ones. The 
reason is that business standards tend to be guidelines as much as standards. 
Technical standards, however, can be much more specific and detailed. These 
standards should also be oriented to the modeling tool or BPMS you have chosen 
and the vendor’s list of best practices. Of course, these standards must also reflect 
current IT and business standards and policy, and, to the extent possible, have 
modifications that support as many of the company’s BPM tools and BPMS as 
possible. As additional standards related to specific IT areas are added, all standards 
should be reviewed and modified to reflect links or eliminate disagreement, 
redundancies and conflict. 

As BPM standards and guidelines are being written, care should be taken to make 
certain they are not a burden. If they become too invasive or too much work, they 
will either be ignored or, if they are monitored, will be given minimal effort — so the 
team can say they complied. To help the standards group understand the burden, 
they must always look at the standards as an aggregation of required work: it helps 
to embed members in projects and make them do the work of complying and 
reporting on the standards so they can understand what they have asked the teams 
to do. 

In order to control the evolution of a company’s BPM tool or BPMS standards, an 
internal BPM Center of Excellence should keep track of all modifications to related 
technical and business standards or guidelines and how they apply to the BPM tool 
and BPMS users in the company. This includes 

• Information Collection: guide the business operation discovery process 


414 


Copyright ABPMP International 


Chapter 10. BPM Technology 


• Simulation: control the information, its quality, and how it is modeled 

• Business Process Modeling Notation (BPMN): used for graphical design of 
processes — defines the way each symbol will be used and provides the 
directions for the generation of BPMS applications 

• Business Process Execution Language (BPEL): for coding BPMS-generated 
applications 

• extensible Markup Language (XML): for sharing data and documents 

• extensible Process Definition Language (XPDL): a file format specification 
that provides a common format for sharing process models between tools 

• Database and data modeling: defines the data that will be supported in the 
models and the schema for data use and storage 

• Java: standards that address the way this language will be used 

• Web services: standards that address construction, use and control 

• SOA: standards that relate to the strategy, use, design etc. of SOA 

• Testing: ensure that generated applications, interfaces, data use, and more 
perform as expected 

Note: This list is representative of the types of standards that should be analyzed. It is 
not meant to be all-inclusive. 

The place to begin the creation of individual BPM tools and BPMS standards is with 
the vendor. The vendor will have a set of recommended standards for using their 
tools. Next, look to BPM associations and other reliable sources for the experiences 
of their members. An Internet search may help, but care must be taken in looking at 
the quality of anything found because the source of any general information found 
on the Internet must always be suspect. If a BPM tool or a BPMS has been used by 
another department in the company, their experiences may be helpful in looking at 
standards. 

As noted above, as new standards are added, care must be taken to consider the 
overall burden that will be placed on teams. The objective is for standards to be 
accepted and used. However, if they become a burden, the teams will find ways to 
do the minimum possible to comply with them. This will defeat the purpose and 
must be avoided. 

10.6 Coming Soon to Help Deliver Flexibility 

BPM technology is constantly evolving as new supporting technologies become 
available. This section talks about four technologies/approaches that may increase 
the flexibility offered by BPM tools and BPMS. 

10.6.1 BPM and SaaS 

Software as a Service (SaaS) is the latest incarnation of the time-sharing concept of 
the late 1970s and the 1980s. In this option, SaaS customers sign on to the vendor’s 
hardware/software environment and use the applications from any location. The 
hardware and applications or tools are located externally to the company and may 
be anyplace in the world. Typically, companies will pay for use based on the amount 
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of the service that is used. In addition, access to these applications and tools is 
generally over the Internet and a significant part of the cost and maintenance 
burden of the classical communications requirements are replaced by Internet 
services. For these reasons, proponents claim that this option is far less expensive 
than in-house systems. 

Some BPM tool vendors are adopting this approach in order to offer lower-priced 
use of their tools by changing their price models to reflect actual use of the tool. This 
promotes collaborative access to the tools by teams located anywhere in the world 
and allows model and data access anytime, from anywhere. In reality, the BPM tool 
user is absolutely independent of the physical location of the computers and their 
mass storage. This is, of course, true for virtually all applications and tools that use 
this access model — depending on the architecture of the applications and the use of 
"thin client" and other technical design approaches. 

When mixed with meeting technology and video conferencing that supports 
common viewing of screens to all meeting participants, this creates a virtual 
teaming capability that supports the offshore Global Delivery Model of global teams, 
so work never stops. 

While claims are made concerning access and data security, time will tell how well 
the vendors’ sites, applications, tools, and data are locked down. Time will also tell 
how well this approach works in resisting hacking and the viruses that plague the 
Internet, not to mention Internet disruptions. For the time being, security and the 
trade-offs that are normally considered may need to be viewed differently in this 
SaaS environment. 

10.6.2 Network Clouds 

A Cloud is a modern Internet-based communications network option that eliminates 
specific point-to-point communications over specific lines — like T1 lines. In "cloud 
computing," the computer and the user have no idea of the path the message is 
taking to get the intended target or end-point. The call and the data packets simply 
are sent by a different route each time, as determined by the communications 
carrier (ATT, Verizon, etc.). As a result, many traditional communication concerns 
cease to be relevant in this environment. This use of a virtual network concept 
eliminates the risk of a single line failure; it also provides unlimited scalability in the 
use of communication services and the ability to take advantage of Internet-based 
features like web browsers. 

As BPM tool vendors move to offer SaaS alternatives to customers, the impact of 
cloud computing will need to be considered. In cases where the BPM technology 
environment actually becomes the business’s IT operating environment, the way 
legacy applications and data are accessed may open new external Internet threats. A 
company’s communications capabilities, the way it allows Internet access, and the 
policies governing Internet use may also require changes to the business and its 
technology architecture. These and many other things must be considered as the 
company looks at the benefits of SaaS and cloud computing in terms of the approach 
it will take in creating a BPM technology environment, the type of tool suites that 
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should be used, and the way BPM will support business activity and continuous 
improvement. 

This open access to Internet services also allows companies to mix elements of the 
work and Internet capabilities to create new and very different approaches to 
accessing applications and tools (see SaaS) to provide new levels of overall access 
reliability. But, as pointed out above, this also opens the company to greater security 
risks from Internet-based attacks. 

In many models, the Internet is simply represented as a cloud to show that the 
communications part of the application or tool "system" is provided by an external 
source that is only partially controlled by the company. SaaS access is often tied 
closely to cloud computing, and in some literature the two cannot be separated. In 
reality, this is true from a use perspective. However, this type of use must be 
considered as a company creates its BPM environment vision and determines how 
BPM tools and techniques will be used in the future. The simple fact is that the use of 
SaaS and cloud computing changes the approach and the architecture of current 
approaches to IT; a move to this technology will create different technical 
requirements that must be part of any IT strategy and planning. 

Because SaaS applications and the Internet cloud are external to the company, 
maintenance of the applications, tools and communication hardware/software are 
also outside the company. A move to new versions of the software is no longer the 
responsibility of the company and the cost of maintenance shifts to the vendor, who 
theoretically spreads the cost of these services over the entire user community. 
While this should lower maintenance costs and improve the quality of any 
maintenance (the vendor is making the changes to their applications or tools), it 
also takes the company out of the upgrade decision process. The vendor may decide 
not to make changes that you need, or may bundle a change you need with an 
enhancement you are not interested in, and they will make changes in their 
timeframe, not yours. This is really an application or tool issue. The impact on 
internal communications will be more related to capabilities that may be needed to 
take advantage of the company's access and other needs. 

10.6.3 Social Networking 

Social media are becoming a force in today’s business world. New CRM and other 
applications are being built to look at the various social networks and mine them for 
customer and product information. What this information will be used for is still 
questionable — this is simply too young a part of business to know. But it is clear that 
the mining of social networks will be rule-driven, and the use of the information will 
feed back to changes in the business and IT operations. To have any real impact, the 
company will need the flexibility to implement the changes driven by social network 
data very fast. This need for rapid change and business evolution is a key driver in 
the move to BPMS technical environments. Only these environments provide the 
ability to change quickly. They are also the only environment that offers control 
over these changes and an ability to work collaboratively with all affected business 
groups to define, simulate, and implement the needed changes. 
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But this environment is based on the creation of current business models with 
defined rules. Until these models are in place, the ability of the company to react to 
information from social media and other sources is restricted to the same approach 
and capabilities that are available today. 

10.6.4 Dynamic Business Applications 

Dynamic Business Applications are applications that can quickly adapt to changing 
business needs, competitive pressure, and market opportunity. They are 
theoretically designed to support continuous change. This ability to adapt quickly, 
change the business, and adapt applications at the pace the business needs has been 
a goal for many years and simply was not well supported before full BPMSs and the 
environment that their technology creates. 

Now it is possible, with full BPMSs and the technical environment they offer, to 
change models, rules, and information and to generate applications very quickly. 
This ability is extended beyond BPM-generated applications to the use of legacy 
applications and data when the company moves to SOA and has the needed SOA/EAI 
legacy application adaptors in place. 

Of course, the ability to change fast requires an ability to look at how the company 
needs to evolve and then control that evolution. It is also important that any rapid 
change preserve the integrity of the other application systems, the business 
operation, and business rules regarding data access and use. 

This flexibility and the speed of change that a fully functioning BPMS environment 
offers is a driving force behind BPM. It relies on the creation of baseline models with 
sound rule definition and the implementation of an SOA environment to support 
access to legacy information. Once this is in place the models can be changed very 
quickly and the BPM applications regenerated. This ability to change quickly and 
constantly makes change support dynamic. 

10.7 Vision of the Future 

In the not-too-distant future, BPMSs will have evolved to the point where they will 
be able to generate code modules that use complex logic in support of transaction- 
level applications. Some vendors claim their BPMS can do this today. As part of this 
direction, BPM is pulling the business user and the IT technician close together and 
promoting a new level of collaboration. With BPM it is not appropriate to simply ask 
users for specs as we have in the past. In BPM the new business models and their 
rules are used to generate business management applications and define the specs 
for legacy application changes. The BPM management applications and the business 
actions performed by people form a model of the business that is executed in the 
BPMS technology environment. The business user actually signs on to applications 
through the BPMS, which then controls the execution of the applications. The result 
is an environment where the business cannot be separated from its systems and 
vice versa. 
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When this happens, the world of IT as we know it will change. The goal is the ability 
to change very fast. To help in this activity, a new type of analyst will be needed. 

This person will have one foot in the business and one foot in IT. But this person will 
be a hybrid between a business designer and a technician. He or she will need to 
understand exactly how the business functions and what is important in performing 
the work along with the BPMS, the legacy applications and the data. 

Many believe that tool availability will be delivered through cloud computing and 
that most application access will be through a cloud-type of service architecture. 

The BPMS vendors are looking at this trend and many are starting to move to this 
type of a model. However, this transition will take time, and it can be expected to lag 
behind other application use models until cloud architecture becomes widely 
accepted. 

But the key to future single-purpose BPM tools and BPMS use and evolution is likely 
to remain focused on ease of use and speed of delivery. These factors are critical to 
building an environment that is geared to support rapid change and thus business 
improvement. 

In the future, the issue will likely change from the question of "can we do this?" to 
"should we do this?" This will change the dynamic in business and IT. As BPMS 
environments become more flexible and offer a greater ability to simply regenerate 
legacy applications, the company will have the ability to do things that it cannot do 
today. In this environment the issues related to access and other types of security 
will need to be balanced with the need to support rapid change. The issues of 
control in the future will thus become even more critical than they are today. 

But the tools still have a long way to go before this becomes reality. So, while this 
environment is coming, advanced companies will have time to deal with an evolving 
set of issues as their use of BPM matures. 

In this journey, BPM vendors will continue to merge, form alliances, and integrate 
their tool suites. The important factor in this ownership shuffling is that any tool 
suite that is chosen should come with guarantees of continued support regardless of 
who may purchase the company or whom the company may purchase. 

While the evolution of BPM tools is set to change the face of business and IT, the 
company’s business strategy will be the driving force behind the adoption of a BPM 
vision. Business strategy must determine the type of technology that is needed to 
deliver the business operation vision. Without this direct tie to strategy and 
operating vision, neither BPM technology nor any other automation can be justified. 
The creation of the business vision must, however, take into account the emerging 
BPM technology capabilities and the potential for a very different and flexible 
business operation. This strategic collaboration between IT and the business will 
need to be somewhat visionary as it reaches out beyond the three-year horizon. The 
needs of the business will clearly drive the limits of the IT vision and the way the 
company’s IT architecture and support vision will change. However, IT 
communications, technical software, and hardware realities will play a significant 
role in determining the evolution of the company and its ability to create a flexible 
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change environment. For these reasons, supporting this new BPM-based vision will 
require a new type of IT strategy that clearly merges company business strategy, 
department operating strategy, and IT strategy to create a realistic acquisition and 
implementation plan. 

The other limiting factor is financial reality. Moving to a full BPM technical 
environment is not simple nor can it be completed quickly. It is also expensive. 
Legacy application-wrapping in a move to SOA is expensive and requires a 
commitment to change the basic technical environment. A move to go beyond using 
BPM tools for specific problem solutions also requires a different vision for IT 
service delivery and a different vision of how the business will operate. This is often 
expensive and difficult to sell. But the implementation of a BPM platform can be 
accomplished gradually, and the amount of disruption to the business can be 
minimized by approaching the move in increments. This will control costs and limit 
risk while allowing the move to be controlled and focused on high-value 
improvements. 

10.8 Summary: Advantages and Risks of Process Automation 

BPM technology is evolving rapidly as vendors leapfrog one another in their drive to 
offer the features and abilities that the market is demanding. This will continue. In 
addition, vendors are consolidating. Bigger ones are buying the competition and we 
can expect that some of these products will be integrated into the purchaser’s 
product suite, while some will simply be sunset. 

The technology side of BPM is both dynamic and visionary. This is a double-edged 
sword: with the advances come the disruption of changing to new versions and the 
cost of migrating systems to these new versions and offerings. But the direction is 
fairly clear, and the fact that BPM is changing the way business and IT interact will 
help companies to deliver improved automated support. 

The past approach of looking at BPM technology to help create solutions to business 
problems has proven the value of BPM, and many companies are now going beyond 
this trial to look at broad use of BPM in their companies. As this happens, an 
understanding of how the technology works and what it can do becomes a key part 
of any BPM professional practitioner's knowledge. Given the evolution of BPM and 
the technology that supports it, the practitioner will need to track changes and 
capabilities and remain current on how the technology of BPM is changing, if he or 
she wants to remain effective. It is this understanding of the evolution of BPM that is 
driving the evolution of the ABPMP CBOK. 

10.9 Key Concepts 

• There are many different ideas of what BPM technology is and what it can do. 
These views are often aligned with what the practitioner’s company is doing 
with BPM. Where this is happening, practitioners need to broaden their 
perspective and consider methods, approaches, techniques, tools and 
capabilities outside their normal exposure. 
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• The use of a BPMS is needed to support rapid change through rules libraries, 
forms generation for screens, application generation, and external technical 
support — legacy application interface, data, web services and Java modules. 
The BPMS uses this information to support rapid iteration and prototyping to 
shorten the overall change cycle. 

• Today there are two different views of BPM technology. These are the 
business view, which focuses on modeling, rules and application generation, 
and the technology view, which focuses on SOA/EAI and ESB with an overlap 
on the need to control rules. These views must be brought together to form a 
full picture of what BPM is and can do. 

• BPM technology is sold as single-purpose tools (modelers, rules engines, etc.) 
or as integrated suites of tools that support all BPM activity from business 
modeling and rules management (with simulation, application generation 
and performance management) to SOA/EAI and ESB. 

• The way the tool or tool suite will be used will be driven by the business view 
of their future change ability. This must support the business vision and 
strategy. 

• A BPM technology strategy must support the business vision, but it must also 
support the financial and acceptance realities in the company. Moving to an 
enterprise or broad use of BPM is a cultural change as well as a technology 
and change approach issue. 

• Tool or tool suite setup is important in determining the way the tool will be 
used and its capabilities. Time should be taken working with the vendor to 
make certain the current and planned use of the tool is part of the 
implementation design. 

• Data access and use must be considered in moving into SOA/EAI. Internet 
use in data or application access carries new risk and capabilities; all must be 
considered in the way this access is allowed. 

• The use of BPM is found in pockets in most companies. This is causing a 
situation where multiple internal business and IT organizations have vested 
interests in their tool or tool suite. 

• It is important that BPM use, naming, quality, testing, and implementation 
methods and standards be put in place. All BPM models and systems should 
be migrated to these common standards so they can eventually be fit 
together to provide enterprise wide information. 

• Few companies have a vision of how BPM can work within their company. 
This is necessary to provide an operating-environment target and a roadmap 
as to how to get there. 

• To be effective, companies need to begin their BPM use with the creation of a 
common business and BPM vocabulary, modeling standards, data quality 
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standards, and much more. This is critical in creating an enterprise model 
and view of the business. 

• Few companies have a BPM architecture or a plan for how BPM will be 
governed. Without this architecture it is impossible to build to an enterprise 
use of BPM. 

• Creating a broad-based BPM environment requires vision and will take years 
to implement. That is why an architecture is needed — to define all the parts 
and how they will fit together. 

• The BPM technology architecture will be a moving target that reflects both 
current BPM and other technology, as well as predicted changes to these 
technologies. It is important that the architecture constantly change and be 
kept up to date to be effective in guiding the BPM environment. 

• Rapid business evolution creates an environment where change can be a core 
competency. The only thing today that provides the level and speed of 
change needed to do this is BPM — it incorporates business change, 
applications generation, and the use of legacy data, to allow a company to 
change fast, and with little risk. This speed is the key to optimization and to 
improved competitiveness. 

• BPM’s ability to support collaboration, governance over the traditional 
business and IT activities in a company will need to evolve. 

• Many BPM tools and tool suites are now offered in a "Software as a Service” 
version. To select this option, it is necessary to consider "cloud computing” 
security and use. 

• The BPM technology of today is a direct result of approximately 25 years of 
evolution. It is changing rapidly as vendors purchase one another and as 
products are merged or sunset. The key is for the BPM practitioner to 
recognize this marketplace and to take steps to protect their company in the 
leasing of any BPM tool or tool suite. 

• BPM tools and tool suites are becoming more robust, and the applications 
they generate are becoming good enough to handle even transaction-system 
needs. As this happens, it will be possible to simply generate many of the 
current legacy applications — once the rules have been mined from them and 
the logic mapped. This will change the face of IT and of business. But the 
move will take time. 
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Glossary 

The purpose of the CBOK Glossary is to define terms for business professionals. The 
definitions are thus not technical in nature but reflect plain business English. To 
help reduce confusion and promote understanding, some terms have descriptive 
information along with the definition. 

ABPMP recognizes that any term in BPM or BPMS today is open to interpretation 
because people apply definitions used wherever they learned the term. 
Consequently, most terms have competing definitions, and this complicates 
communication in companies and among BPM professionals. In creating this 
glossary, we had to decide whether to list numerous competing definitions or to 
provide a standard definition for each term. Our goal was to create consistency in 
BPM discussions for the BPM industry and our members, so we have provided a 
single standard definition for all terms. This glossary is thus a step in achieving the 
ABPMP goal of creating a standard understanding of BPM throughout the world. 

Although these definitions may be somewhat different from those you currently use, 
they are the ABPMP standard definitions and are used throughout the CBOK. 
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A 

Activity 

The aggregation of tasks needed to deliver a definable part of a sub assembly or 
service. An example is the milling of a part that will become part of a sub assembly. 
Here the raw material will need to be heat treated, then milled, then degreased, then 
polished, then tested for tolerance. These tasks form a definable outcome or part of 
a sub assembly. In a service business (insurance), an example is the claim review, 
which may be part of the claim adjudication subprocess, which in turn may be part 
of the line of business management process. Activities can aggregate to form 
scenarios. These are groups of activities and their tasks that are always executed in 
certain events or in response to specific needs — such as customer registration or 
on-boarding in a banking wealth management line of business. 

Activity Based Costing 

An approach to cost accounting. It starts by determining how much it costs to 
perform a given activity in a process, and then adds up costs of all activities in the 
process to determine the total process costs. Fixed, variable, and direct costs 
associated with the activity are considered. This analytical technique is used as part 
of a business transformation effort to gain an understanding of the cost and income 
associated with a product or service, in order to determine true profitability. 

Agile Methodology 

One of several software development methodologies based on iterative and 
incremental development, as opposed to traditional linear or waterfall-type 
software development methodologies. An agile methodology provides a framework 
to support the design, development, and testing of software solutions throughout 
their life cycle. 

Agile methods (e.g., Scrum) encourage rapid and flexible responses to change by 
promoting adaptive planning, collaborative requirement identification, and 
rationalization between self-organizing cross-functional team, as well as time- 
boxed, incremental development of solutions. Many modern commercial software 
development efforts follow this type of approach. 

Architecture 

In process modeling, a purposeful arrangement of models in a framework that 
describes a whole business in terms of its component parts. These may be created in 
compliance with well-known frameworks to reduce ambiguity. Examples include 
architectures based on The Zachman Framework and its derivatives, such as The 
Open Group Architectural Framework (TOGAF). 

ARIS (Architecture of Integrated Information Systems) 

An approach to enterprise modeling. It offers methods for analyzing processes and 
taking a holistic view of process design-management workflow and application 
processing. The ARIS approach provides a well-documented, methodological 
framework for BPM, based on Prof. August Wilhelm Scheer’s research from the 


424 


Copyright ABPMP International 


Glossary 


1990s. ARIS uses a modeling language known as Event Driven Process Chain (EPC), 
which brings multiple aspects of enterprise modeling together using the ARIS House 
of Business Engineering framework. 

B 

Benchmarking 

A comparison of the performance of a process in one organization to performance of 
similar processes in companies within the same industry. Many companies seek 
benchmark data to help with business transformation efforts and determine how 
well other companies are managing similar processes. 

Big Data 

Data from the outside world, obtained from social media, sensors, and mobile 
capture. 

Bottleneck 

A constraint that creates a backlog around the "bottleneck." Usually, these 
constraints prevent the system from achieving more of its goals. There are many 
ways the constraints can show up. They can be internal or external to the system 
types and could be a result of equipment, people, policies, or ineffective processes. 
Identifying constraints and alleviating bottlenecks are often a key objective of 
business transformation projects. 

Business Analysts (BAs) 

A person performing this role is responsible for analyzing the business operation’s 
work and workflow to help propose changes that will eliminate problems, cut cost, 
improve quality, and improve customer interaction. Once improvements are 
identified, the Business Analyst then defines how information technology changes 
can improve the business operation. Business Analysts usually work as part of the 
process team. 

Business Architecture 

The design of a business operation, usually described in terms of business 
capabilities and supporting technology capabilities. This design is conceptual and is 
used to determine how a business will need to change to support a given strategy. 

Business Architect 

A person performing this role is responsible for determining how the business 
operation needs to change to support business strategy. The Business Architect 
works with the corporate planning group to define the business outcomes needed to 
deliver the strategy, and to identify how the current and anticipated business 
capabilities will need to change in order to produce these defined outcomes. The 
Business Architect then works with the Process Architect to define how the 
company’s processes must change to support this mix of current/modified and new 
business capabilities. 
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Business Process Improvement (BPI) 

Business process improvement focuses on incrementally improving existing 
processes. There are many approaches, including the popular Six Sigma approach. 
BPI is usually narrowly focused and continuously applied at various stages during 
the life of a process. BPI includes the selection, analysis, design, and implementation 
of the (improved) process. This usually results in an initiative or project to improve 
the performance of a particular process in alignment with the organizational 
strategy and customer expectations. 

Business Process Management (BPM) 

BPM is a management discipline that integrates the strategy and goals of an 
organization with the expectations and needs of customers by focusing on end-to- 
end processes. It brings together strategies, goals, culture, organizational structures, 
roles, policies, methodologies, and IT tools to 

(a) Analyze, design, implement, control, and continuously improve end-to-end 
processes, and 

(b) Establish process governance. 

It is focused on delivering operational improvement, or, in a large-scale change, 
transformation. This process-centric approach to business management is 
supported by automated tools to deliver an operational environment that supports 
rapid change and continuous improvement. BPM provides a view of the business 
activity through the use of process models with clearly visible associated business 
and technical operational rules. 

BPM Methodology 

A formal, written, comprehensive list of organized tasks with supporting 
documentation on how the tasks should be performed, the data that the team should 
look for, and identification of the deliverables from tasks. All together, this 
information should provide direction on how the BPMS/BPM project should be 
done. 

Business Process Management Center of Excellence (BPMCOE) 

An internal group within a company, which specializes in BPM and BPMS use and 
helps the business address enterprise process management and performance issues. 

Business Process Management Operating Environment 

BPM today melds Business Process design, improvement, and transformation 
methods and techniques, with Business Process Management Suite (BPMS) 
automation capabilities to achieve radical Business Transformation. In this 
emerging environment, the BPM teams use the full spectrum of BPMS tools to 
deliver business and IT change. Together, BPM and BPMS form a new operating 
environment that integrates new business management automation with legacy 
production applications to open access to data and functionality. 
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Business Process Modeling 

The set of activities involved in creating representations of an existing or proposed 
business process. It can provide an end-to-end perspective or a portion of an 
organization's primary, supporting or management processes. 

Business Process Modeling Notation (BPMN) 

A set of graphical standards that specify the symbol sets that will be used in BPM 
diagrams/models. As such, they define the symbols that will be used in depicting 
process and workflow in business modeling. 

Created by the Business Process Management Initiative, now merged with the 
Object Management Group (OMG), an information systems standards setting group, 
BPMN has growing acceptance as a standard from many perspectives, which has 
resulted in its inclusion in several of the most widely used modeling tools. It 
provides a robust symbol set for modeling different aspects of business processes. 
Like most modern notations, the symbols describe definite relationships such as 
workflow and order of precedence. 

In addition to symbol standardization, BPMN attempts to standardize terminology 
and modeling technique. It serves a purpose similar to the Event Process Chain 
(EPC) notation used in the ARIS methodology. 

This standard has gone through several iterations, the latest being 2.0. However, the 
standard will continue to be modified and the version number and content will 
change. It is anticipated that the BPM modeling tool vendors and BPMS vendors will 
adjust to the standards as they change. 

Although BPMN provides a set of standard modeling symbols, most organizations 
will still need to apply their own architectural and engineering standards to have a 
complete BPM modeling solution. 

Business Process Management Suites (BPMS) 

A set of automated tools that allows the business to be modeled, showing flow, rule 
use, data use and more. This provides an integrated suite of software that defines 
the application architecture and infrastructure technology needs for the operation 
and execution of the applications that run within the BPMS technical environment. 
The BPMS operating environment addresses business users' desire to see and 
manage work as it progresses across organizational activity. 

A BPMS supports process modeling, design, development, and the managed 
execution of work and applications. The information in the BPMS design and rules 
libraries is used to automatically generate the applications that are used in the 
solution. This allows very fast change, with control over the way the change will be 
applied. 

A BPMS provides a new type of business environment that melds the business and 
IT. We use the term "environment" to describe the resulting operation when using a 
BPMS, because these tool suites generate the applications and provide the overall 
operating environment through which the business and the applications run. 
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While component parts of these tool suites have existed since the late 1980s, they 
were not combined until a breakthrough in the early 2000’s. The real breakthrough 
that allowed this coalescing of products was the advent of rules-based application 
generation that was tied to process models. Since 2003, various component 
products have been brought together to form BPM product suites. It is the melding 
of the BPM approaches, techniques, and tools, along with their ability to quickly 
generate applications, which delivers the speed needed to optimize an operation 
and to support rapid change. This ability is what delivers both initial optimization 
and continuous improvement. 

BPMS Architecture 

A design of how the various component software tools that work together to 
provide a BPMS environment fit together. 

BPMS/BPM or BPMS-Supported BPM 

A business operation that follows a BPM approach to improvement using a BPMS 
tool to drive and support business activity and coordinate the use of legacy IT 
applications. This forms an operating "environment" where the business actually 
runs using the BPMS. 

BPMS Repositories 

Electronic databases (repositories) that have the ability to store a majority of an 
organization’s business process information in a single location. This can 
significantly reduce the need for managing large volumes of Microsoft Office 
documents (e.g., Word, Excel and Visio) and simplifies version control. They do not 
however, usually store all the real-time data that is collected from transactions 
processed through the BPMS-supported business operation (through data entry in 
the screens that are used) or obtained from Legacy Business Applications or 
Databases. 

Business Process Transformation 

The fundamental rethinking of a process. This is focused on the end-to-end 
alignment and change of a business’s functions, processes, organization, data, 
metrics, and technology in accordance with the strategic objectives and tactical 
demands of the business, delivering a significant, measured increase in customer 
value. 

The goal is innovation and the application of new concepts, capabilities, technology, 
etc., to the design of the work that needs to be done. In this business redesign, no 
idea is off the table. No option is initially rejected — unless by company policy, law or 
financial reality. Improvement is thus not the goal, but a by-product of a radical 
change to the way the process is approached and performed. This level of change is 
by nature invasive and will be disruptive. 
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C 

Capability Maturity Model (CMM) 

A Capability Maturity Model (CMM) lists important activities common to similar 
organizations and provides rating scales (e.g., 1-5) for each activity, along with 
descriptions of what each rating means. A CMM is a way of evaluating how well an 
organization does what it does. CobiT is an example of a framework that contains a 
CMM used to rate the activities of Informational Technology divisions across all 
stages of service design and implementation. The ratings of a CMM may be 
correlated to other measures of organizational success, such as brand value, 
profitability, and market growth. 

A CMM, when used by external, impartial, third-party evaluators, helps other 
interested parties compare multiple organizations. When used internally, a CMM 
can be used to establish an organizational vision, and organizational and individual 
goals. This helps set the time-frame in which an organization may achieve each level 
of the CMM. 

Change Management 

A structured approach to manage the people- and organization-related aspects of 
change to achieve the desired business outcomes. It is aimed at helping 
management, employees and stakeholders to accept and embrace change in their 
current business environment. This often involves conducting formal change-impact 
assessments, developing individual action plans, improving communications, and 
providing training to counter resistance. The result is that these plans help align 
changes to the overall strategic direction of the organization. 

Continuous Improvement 

An approach to operational process improvement that is based on the need to 
continually review operations for problems, cost reduction opportunity, 
streamlining, and other factors that together allow optimization. Often associated 
with process methodologies, continuous improvement activity provides ongoing 
insight, measurement, and feedback on process performance to drive improvement 
in the execution of processes. 

In Continuous Improvement (following evaluation techniques like Six Sigma) 
business managers work with BPM and IT professionals to implement performance 
monitoring and measurement — i.e., to identify, define, measure, analyze, improve 
and control business processes. This leads to an ongoing list of improvement 
opportunities and related projects that allow the company to optimize its 
operations. 

Critical Success Factor (CSF) 

Critical Success Factors (CSFs) are those activities and capabilities that are essential 
for a company to succeed in its market. CSFs are those few things that absolutely, 
positively must go right to ensure success for the organization. Because these 
factors are industry- and at times geographically-specific, they will vary from 
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company to company. These factors relate to what the company needs to do to 
succeed in a continuous manner, not necessarily what it is currently doing. 

Typically referring to process-related improvement programs, CSFs are the key 
factors as relayed by stakeholders that are important to the success of the 
project/program. 

Cross-functional processes 

See Enterprise Process Management 

Cloud Computing 

Cloud Computing is the delivery of computing resources to an organization as a 
complete service over the Internet, rather than having the organization purchase 
each component separately and internally manage and support the computing 
resource. Think of it as renting a computing resource instead of buying, building, 
and operating your own computing infrastructure. Similar to the "time-share" 
computing services of the 1970s, 1980s and 1990s, cloud computing provides users 
with access to software applications, data, hardware and support resources without 
the users needing to know the location and other details of the computing 
environment. End-users access cloud-based applications through a Web browser. 
Access is to business software and data that are stored on servers at remote 
locations. Cloud Computing is also referred to as Software as a Service (SaaS). 

D 

Data Flow Analysis 

An analysis technique that seeks to understand how data flows through a system. It 
looks at data use in different parts of an organization as well as how data is used by 
applications supporting a given business process. 

DCOR™ 

Design Chain Operations Reference: a reference model created by the Supply Chain 
Council. 

Dynamic Business Applications 

Applications that can quickly adapt to changing business needs, competitive 
pressure, and market opportunity. 

E 

Enterprise Process Management (EPM) 

EPM is the application of BPM principles, methods, and processes to an individual 
enterprise. It (a) assures the alignment of the portfolio and architecture of end-to- 
end processes with the organization’s strategy and resources, and (b) provides a 
governance model for the management and evaluation of BPM initiatives. 

Enterprise Process Model(s) 

A model that shows the full end-to-end activity (high-level view) needed to create 
the outcome (service or product) of the process. Enterprise Process Models may 
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also be known as value chain models. Depending on the needs of the organization or 
project, these models can be created, at different levels of detail — processes 
decomposed into subprocesses, activities, and tasks — to provide a complete 
functional view. 

Enterprise Resource Planning (ERP) systems 

A pre-packaged set of business software applications that help integrate internal 
and external management information across an organization. Typical areas of 
functionality include finance/accounting, sales and service, manufacturing, 
inventory management, procurement and customer relationship management. ERP 
systems can run on a variety of computing platforms, and typically feature a central 
database for storing information. 

Enterprise Service Bus (ESB) 

A software architecture — supported by a set of software tools, software, and a 
communication medium or carrier — that moves data between applications and 
communications equipment. The combined ESB components control the movement 
of data between computers. 

Event Process Chain (EPC) 

Event-driven Process Chain models are a type of flowchart used for business 
process modeling. They serve a purpose similar to BPMN models in supporting 
business process improvement by helping to link different views of an enterprise 
model together. An EPC considers "events" as triggers to or results from a process 
step; this is useful for modeling complex sets of processes. EPC triggers resulting 
from a process step are called "functions." Thus, the flow is normally event-function- 
event. 

F 

Failure Mode and Effects Analysis (FMEA) 

A FMEA is a Six Sigma risk assessment technique that identifies how a product, 
service, or process can fail, estimates the related risks, and prioritizes actions that 
reduce the risk of failure. 

Flow Charting 

A type of diagram that represents in visual format a sequence of events, processing 
steps, and/or decisions. Originally approved as an ANSI standard, flow charting 
includes a very simple and small set of symbols, which are not standardized; it 
facilitates "quick capture" of process flow. 

Framework 

In process modeling, a framework is any planned association among the models 
applied to meet a policy, design, or usability requirement. The framework may or 
may not be architecturally significant. Example: a value chain for a process, with 
overlays depicting aspects of performers, timing, and financial elements, and with 
event chains describing details of process steps. 
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G 

BPM Governance 

BPM Governance orchestrates the process of process management and provides a 
sustainable continuous process improvement capability, which is aligned with the 
business strategy. 

H 

Handoffs 

Any point in a process where work or information passes from one system, person, 
or group to another is a "handoff" for that process. Handoffs are often illustrated as 
process interfaces or intermediary events. 

I 

Integrated Definition Language (IDEF) 

A Federal Information Processing Standard that highlights the inputs, outputs, 
mechanisms, and controls of a process, and clearly links processes up and down 
levels of detail; IDEF is a good starting place for an enterprise-wide view of an 
organization. 

ITIL 

ITIL stands for Information Technology Infrastructure Library. It is a collection of 
best practices for Information Technology (IT) service management. 

J 

K 

Key Performance Indicator (KPI) 

KPI refers to the metrics or measures of a process that are indicative of overall 
performance. 

Companies that measure performance should have set targets and standards for 
measuring performance on those things they consider to be really important. These 
measures are called Key Performance Indicators (KPIs). KPI’s measure factors that 
management believes are an indication of operational excellence. To be a realistic 
indicator, each KPI should be based on a reasonable target and should change over 
time as the business improves. 

L 

Lean 

A philosophy and approach that stresses the elimination of waste or non-value-add 
work through a focus on continuous improvement to streamline the operations. It is 
customer-centric and stresses the concept of eliminating any activity that fails to 
add value to the creation or delivery of a product or service. Lean is focused on 
providing higher quality, reduced cycle time, and lower costs. Because it produces 
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improved production systems, it is believed to increase production capability and 
flexibility. But in practice, its concepts can be, and have been, applied in all areas of a 
business. James Womack and Daniel Jones developed the term "Lean" in their book 
about the Toyota Production System (TPS), The Machine That Changed the 
World. Today, Lean is supported by tools and statistical methods that, although not 
as robust as those of Six Sigma, are an important part of improvement projects. For 
the most part Lean has been used in manufacturing, where organizations are 
applying Lean tools in service and transactional settings with great success. Typical 
results show dramatic reductions in time while significantly boosting quality. This 
approach is sometimes combined with Six Sigma techniques and referred to as 
Lean/Six Sigma (L-SS). 

M 

Measurement 

The quantification of data (or data set) in an acceptable standard and quality 
(accuracy, completeness, consistency, and timeliness). 

Measurable Activity 

Any properly defined activity is measurable. At a minimum, the number of cases 
coming into the activity, the time in the activity, the error rate, and multiple other 
factors can be measured. That an activity can be measured however, does not mean 
it should be measured. A measurable activity is one that should be measured. It may 
be a cost driver, a quality checkpoint, or something else. But care should be taken in 
identifying measurable activity because it is easy to measure the wrong things, and 
it is easy to over-measure and create worthless reports. 

Metric 

A quantitative measure of a given attribute in a system, component, or process. 
Metric represents an extrapolation or a mathematical calculation of measurements, 
resulting in a derived value. 

Modernization 

Activity that uses the knowledge of the current operation and leverages new 
technology, new manufacturing techniques, and new management philosophies to 
define how the products or services will be produced by the operation. 

N 

Notation 

The specific set of symbols and their rules of usage in describing a thing. There are 
notations created or adapted for use in BPM, just as in other fields. Flowcharting is 
an example of a notation used both for business process documentation and for 
documenting computer-programming logic. Other examples include BPMN and EPC. 
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O 

P 

Performance Management 

Performance Management is the use of performance information to control the 
process or workflow/business unit’s productivity, quality, cost, etc., against 
predetermined targets. This measurement information is used to direct specific 
improvement that helps reach performance targets. 

Performance Measurement 

All business activities can be monitored, measured, and evaluated when properly 
understood and modeled. Although this measurement can be used to monitor the 
overall performance of a process, it typically refers to the measurement of groups of 
activities against specific standards, targets, KPIs or success factors. 

Performance Evaluation 

The identification of gaps between how a process is currently performing in relation 
to how it should be performing to meet the organization's objectives. This 
evaluation can be against standards, targets or existing performance. 

Process 

A process is a set of functions in a certain sequence that delivers value to a 
customer. Processes are started by clearly defined external events. 

They are formed from a combination of all the activities and support that are needed 
to produce and deliver an objective, outcome, product or service, regardless of 
where the activity is performed. These activities are usually a cross-functional, 
cross-organization aggregation of activities that work together to create an end 
product or service. Activities are shown in the context of their relationship with one 
another to provide a picture of sequence and flow. 

This context includes a defined set of activities or behaviors performed by humans, 
systems, or a combination of both to achieve one or more goals. Processes are 
triggered by specific events and have one or more outcomes that may result in the 
termination of the process or a handoff to another process. Processes are composed 
of a collection of interrelated tasks or activities that solve a particular issue. In the 
context of business process management, a "business process" is defined as end-to- 
end work that delivers value to customers. The notion of end-to-end work is critical 
as it involves all of the work, crossing any functional boundaries, necessary to 
completely deliver customer value. 

Process Analysis 

Process analysis is the act of conducting a thorough review and arriving at a 
complete understanding of a business process (or portion thereof), with the goal of 
maintaining or achieving process excellence, or achieving incremental to 
transformational improvements in a business process. 
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Process analysis involves looking at all components of a process — inputs, outputs, 
mechanisms and controls — inspecting each component individually and as they 
interact to produce results. These components can often be categorized into the 
people, processes, applications, data, and technology needed to support a business 
goal or objective. Analyses cover and uncover quality, time, and costs at all points of 
a business process, from inception to completion. 

Aids to process analysis include 

• Visual process models, both static and dynamic 

• Data collected at the beginning, duration, and end of key activities, lower- 
level processes, and the entire business process itself 

• Business process analysis methods such as value chain analysis, end-to- 
end modeling, and functional decomposition. 

Some typical process analyses are 

• Resource utilization 

• Distribution analysis 

• Cycle time analysis 

• Cost analysis 

• Software application usage 

• Global/Local process variations. 

Holistic business process analyses evaluate 

• Total cost of the process tools (e.g., computer systems) 

• Impact of the process on internal participants (employees) and external 
(paying) customers and stakeholders 

• Impact of the process on the organization’s community (e.g., 
environmental impacts) and other stakeholders. 

Process Analyst 

A person with this role is responsible for working with business managers and staff 
to define and validate the current business operation and design future process 
models with business participants, Process Architects and Process Designers. Their 
role is to help identify how a business operation really functions and then to help 
identify, design, build and deploy improvement. They are often called upon to train 
project team members on modeling standards and approaches as defined by the 
Process Architect and Business Architect. 

Process Manager or Leader 

A person with this role manages process transformation projects, leads process 
discovery and design workshops, coaches process owners, and measures and 
reports on process performance. 

Process Architect 

A person with this role is focused on defining, redesigning, and optimizing activities 
in a process or group of processes. These people work with Business Architects to 
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look at how processes need to change to deliver business goals, with Solution 
Architects to ensure performance, maintainability, and scalability, and with 
Enterprise Architects to identify IT capability, limitations, and support changes. 

Process Component 

The parts of a process: inputs, outputs, mechanisms, and controls. 

• Inputs are resources or data that must be present, and "triggers" " (different 
types of events) that invoke a process. 

• Mechanisms are the "tools," including machines, systems, and people, that 
perform "activities," the actions upon and in response to the inputs. 

• Controls are the requirements, constraints, guides, and restraints; and 
defining laws, policies, rules and regulations that shape and determine the 
actions upon the inputs. Mechanisms and controls can be the same: for 
example, regulations, money, or people. 

• Outputs are the results of the actions of the mechanisms, guided by the 
controls and mechanisms, upon the inputs. Optimally, outputs are services or 
products meeting or exceeding the time, quality, or cost expectations of an 
organization’s customers. They may also be events that trigger other 
processes in the same or in a different organization. 

Process Culture 

Organizations where the business’s processes are known, agreed on, communicated, 
and visible to all employees. 

Process Design 

Process design is the act of transforming an organization’s vision, goals, and 
available resources into a discernible, measureable means of achieving the 
organization’s vision. Process design may start with process analysis; best practices 
from similar organizations; process reference models from industry-standards 
organizations (e.g., SCOR or eTOM) or third party consultants; or "green field" — 
ideas coupled with the experience and insights of the process design team. Process 
design focuses on defining what the organization will do to achieve its financial and 
other goals. 

Process Designer 

A person in this role works with business managers and staff to define and validate 
the future-state operational design of processes. The Process Designer is thus the 
catalyst to the future-state design and its continuous evolution. These people 
understand the mechanisms of the business and know how to develop a solution 
that meets performance targets, is scalable, and can be easily maintained. The 
Process Architect views the process from the perspective of how it interacts with 
the bigger picture (outside in). 

Process Flow 

The aggregation of subprocesses into a sequential relationship that shows the order 
in which they are performed. 
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Process Management Maturity 

A measure of the state of a company’s journey to consider and manage work using a 
process centric approach. The level of maturity is defined by comparing the 
company’s current operation against characteristics and capabilities that are 
defined in one of the many Process Maturity Models in the market. 

Process Manager 

A person in this role performs and coordinates the work on a process or processes 
and manages the process/processes’ business performance. 

Process Modeling 

Process modeling is the act of creating visible illustrations, which can be static or 
dynamic, of what an organization does to produce services or products (optimally of 
value to one or more customers). Optimally, process modeling results in an 
illustration that an independent evaluator can compare and match to the 
organization’s process. 

Process Organization 

An organization that is structured, organized, managed, and measured around its 
primary business processes. Its knowledge area addresses two types of 
organizations: 

• The process-driven organization 

• The roles and responsibilities of the governing bodies needed to support the 
process- driven organization. 

Process Owner 

A person in this role has the ongoing responsibility and accountability for the 
successful design, development, execution, and performance of a complete end-to- 
end (cross-functional) business process. 

Process ownership can be adopted full time or as an additional responsibility, as a 
line or staff function. 

Executive process owners (Enterprise Process Owners and Chief Process Officers) 
commonly have financial responsibility for groups of business processes. They have 
an inherent investment in the successful execution of cross-functional business 
processes that are key to the success of the company. 

Process owners are among the essentials to business process success. A business 
process without an organizationally influential process owner is like a ship without 
a rudder, propeller, and sails — the business process can’t execute in the most 
efficient and effective way possible. 

Process Team 

A process team is a process owner and the supporting "players" who define, analyze, 
and refine a business process. 

The more common process team roles include 
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• Process manager, 

• Process analyst, 

• Process designer, and 

• Process architect, along with 

• Business analyst, 

• Subject matter expert, and 

• Executive management and leadership 

Process teams are often advised by a Business Architect and/or Process Architect. 

Q 

R 

Reference Model 

A normalized model that provides a high-level integrated view of a business, its 
technology, and its data; it is used as a reference for building similar models. 
Reference models are useful in providing a degree of standardization among 
elements of a discipline. A well-known reference model is the supply-chain 
operations reference (SCOR), which allows for describing supply chains using 
common terminology and relationships to aid in comparisons and diagnostics. 

Another popular industry reference model is the eTOM or Enhanced Telecom 
Operations Map published by the TM Forum. The eTOM model describes the full 
scope of business processes required by a telecom company and defines key 
organizational and business process elements and how they interact. eTOM is often 
associated with ITIL, a standard framework for best practices in information 
technology. Many consulting organizations also offer business process reference 
models for specific industries. 

Risk Analysis 

Examines the effectiveness of process control points against given stresses to 
determine when something will fail. It also can mean the level of risk that can be 
expected in a given course of action and the probability of failure — such as the 
probability of project failure if a given action is or is not taken. 

Role 

A business role is a group of related skills with a level of authority to perform a 
given task. This includes all task types whether they are a manual or system 
enabled. Business roles are not the same as: 

• Organizational Jobs — a job is a role that exists in the organization and 
comprises a common set of responsibilities. For example, a manager’s job 
includes performing the function of a department manager and being 
responsible for direct report employees. 

• Organizational Positions — an organizational position is a specific opening 
that someone fills (in a specific location). This is a skill- and location-specific 
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opening that is filled by a specific person. For example, a departmental 
manager in the San Francisco office. 

• Security Roles — a security role is a tactical object that gets assigned to a 
user ID, and allows the user access to the system. 

Rules 

The logic that defines what will be done, when it will be done, where it will be done, 
why it will be done, how it will be done, and how it will all be managed or governed. 
Rules can take many forms, from simple binary decisions to decisions involving 
more advanced Boolean logic rules. Examples range from simple yes/no decisions to 
multi-threaded decision trees to determine how a process responds to a given event. 

S 

SCOR® 

Supply Chain Operations Reference (SCOR) is business process reference model 
endorsed by the Supply Chain Council as a de-facto standard diagnostic tool for 
supply chain management. SCOR is a management tool spanning an organization’s 
suppliers to its customers. This reference describes the business activities 
associated with all phases of satisfying the customer's demands. This reference 
model looks at business processes and activities used in all stages of supply chain 
activity. The SCOR a model is based on three major pillars: process modeling, 
performance measurements, and best practices. The process model is divided into 
five groups: Plan, Source, Make, Deliver, and Return. Each of these process groups is 
decomposed into progressively lower levels of detail to help model supply chain 
activities. Each level is a decomposition of the activities in the level above and all are 
supported by a set of standard key performance indicators (KPI). 

Sensitivity Analysis (also known as a "what if" analysis) 

An analytical technique that tries to determine the outcome of changes to the 
parameters of or the activities in a process. This is a measure of the sensitivity of 
something to a given change. It measures the hypothetical impact of different types 
of change (such as capacity, financial issues) on the overall process, workflow, or 
activity, and it is useful for determining how a change may impact the operation. It is 
also known as "what if analysis" and is used to support decision-making or the 
development of recommendations for decision-makers based on changing certain 
variables in the analytical model. 

Also called hypothesis testing, the goal is to test the measurable outcomes of 
performance (e.g. time, cost) from different ways to achieve desired objectives. 

Service Level Agreement (SLA) 

An agreement between two or multiple parties that defines specific levels of 
performance related to given activities. The SLAs are targets or standards that must 
be met by a supplier, outsourcing company, vendor, service provider or partner. 
SLAs are written in plain language specifying the target performance levels and how 
the target performance will be measured. They include the timing of the agreed 
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measurement and a clearly defined issue resolution and escalation process for all 
parties agreeing to the SLA. An SLA may also build in penalties or incentives tied to 
performance targets for improved performance or for excellence. 

As related to a process, SLAs focus on measureable outcomes that have been defined 
by stakeholders to meet set performance criteria. 

Simulation 

A modeling technique that uses business process models in a BPMS tool to make 
predictions about how a process may perform under different circumstances and 
workloads. Business process simulation can be either formal or informal and use a 
variety of techniques. Process simulation usually assigns values to activities and 
then defines a number of anticipated use cases to see how the business process will 
respond under different circumstances. The simulation of complex business 
processes can often reveal outcomes that business process transformation teams 
can't anticipate. This is especially relevant when trying to model new automated 
business processes being carried out on mobile devices. Simulations require 
sufficient data, which typically allows the process to be mathematically simulated 
under various scenarios, loads, or other conditions. 

SIPOC 

SIPOC is a Six Sigma tool; it stands for "Supplier-Input-Process-Output-Customer". A 
SIPOC diagram verifies that process inputs match outputs of the upstream process 
and that process outputs match the expected inputs of the downstream process. 

Six Sigma 

A method that drives business performance improvement by reducing or narrowing 
variation in work or in quality. The goal is to reach a statistical variation of Six Sigma 
(or six standard deviations of variation) within the limits defined by the customer’s 
specifications. Since its introduction in 1987, Six Sigma has become one of the most 
recognized enterprise improvement methodologies for companies seeking to 
identify business problems, define improvement opportunities and projects, and 
deliver solutions to realize predictable and repeatable results. 

SOA 

An approach for linking resources to obtain or present data on an "on demand’ 
basis. It is a data access and delivery strategy pursued by the enterprise — it is not 
simply a tactic or technique that the enterprise adopts to pursue a goal of improved 
application interfacing. 

Service Oriented Architecture (SOA), is an approach for building computing 
applications that support or automate business processes by using a set of loosely 
coupled black-box components. SOA represents a dramatic change in the 
relationship between business and IT. SOA makes technology a true business 
enabler and empowers business and technology leaders alike. 
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From a technical perspective, SOA is a method to design and architect solutions. It 
could be implemented in a messaging or integration layer or it could be a way that 
an application is designed to provide services to other applications. 

SOA Implementation 

A project or initiative to implement business solutions using SOA technology. 

SOA Execution 

A program to invoke a service, but does not contain 'business logic'. 

SOA Interface 

The software that calls data from, or presents data to, one or more applications that 
are external to the application being executed. The interface address information 
for locating the associated implementation(s) is called the request. 

SOAP 

Imbedded within the SOA umbrella is a set of standards that govern data transfer. 
These standards, named Simple Object Access Protocol (SOAP), are a set of rules for 
transferring structured information across a network in the implementation of Web 
Services . 

Swim Lanes 

Swim lane models divide a screen or page into multiple parallel lines or lanes. The 
lanes are generally represented as long vertical or horizontal rectangles or 
sometimes-simple lines or bars. Each of these lanes is defined as a specific 
organization unit or a business role that a person plays in performing the work. The 
work moves from activity to activity following the path of the flow from business 
unit to business unit or from role to role. By showing the flow from lane (role/ 
organization) to lane, swim lanes help identify hand-offs in a process. 

Software as a Service (SaaS) 

Sometimes referred to as on-demand software, SaaS is a software delivery model in 
which application software and its associated data and infrastructure are hosted on 
the Internet and accessed by users with a web browser. This is the latest incarnation 
of the time-sharing concept of the late 1970s and the 1980s. In this option, SaaS 
customers sign on to the vendor’s hardware/software environment and use the 
applications from any location (common examples include sales force and payroll 
automation). The hardware and applications or tools are located externally to the 
company and may be anyplace in the world. SaaS computing services and 
applications are typically managed and supported by a third-party vendor on a fee- 
for-service basis. 

Strategic BPM Planning 

Strategic BPM Planning defines the way BPM and BPMS will be used in the company. 
It translates the vision of business improvement into action plans and aligns 
required BPM/BPMS capabilities with the approach that will be taken in improving 
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business processes. This is important in delivering the business objectives of 
transformation projects. 

Subject Matter Experts (SMEs) 

These individuals are typically people who have a deep understanding of certain 
business functions or operations, often possessing years of experience as a 
participant in business operations. This term is also applied to people who have 
deep expertise in an area of IT, production operations, supply chain management or 
other areas of activity. 

Success Criteria 

The topics or items that a project must address and the standards, targets, and 
limits that must be achieved in order for it to be a success. 

Systems Dynamics Models 

These models are "activity on arrow" diagrams rather than "activity on node" 
diagrams like most of the other notations. These are more often used to model an 
entire enterprise or line of business than to model lower-level workflow. They 
describe the enterprise business "architecture" from a dynamic behavioral 
perspective rather than a static structural perspective. 

T 

Task 

The steps or actions taken to perform a specific piece of work — such as to enter a 
claim’s information into the line of business’ claim system, register a patient in a 
hospital, or enter an order for a project into a sales system. A number of logically 
related tasks can be combined into a higher-level "Activity". A task may or may not 
have automated support. Some tasks can even be totally automated. These may be 
shown in a workflow model to provide information that helps staff understand what 
is happening. Tasks can also combine to form scenarios that are repeated based on 
events, timing, etc. 

U 

Unified Modeling Language (UML) 

Maintained by the Object Management Group, a standard set of diagramming 
technique notations primarily for describing information systems requirements. 
UML models are most often associated with custom software development efforts, 
though they may also be associated with the custom development portions of an 
ERP implementation project for defining custom reports, interfaces, conversions, 
and enhancement (RICE) objects. 

V 

Value Chain 

Value chains are large-scale business processes that are initiated by a customer 
request, and result in the delivery of a process or service to a customer. A value 
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chain includes everything that contributes to the delivery of a given product. By 
adding up all the costs of each activity in the value chain, and subtracting the total 
from the sales price, an organization can determine the profit margin on the value 
chain. Most organizations support from 3 to 15 value chains. Introduced by Michael 
Porter in his 1985 book entitled Competitive Advantage, this approach emphasizes 
capturing those processes and activities that "add value" to the service or product 
provided to a customer. Value Chains provide a strategic view of business processes 
across the organizations and products they support. 

Value Chain Notations 

A category of symbol sets used to visualize the accumulation of value or steps 
toward achievement of a goal. 

Value Stream Mapping 

A Value Stream Map is a Lean Six Sigma tool used for detailed process analysis and 
design. It captures all key process activities and metrics, and focuses on eliminating 
activities that do not add value to the product or service being built or delivered. 

In Lean Manufacturing, this is used to add process resource costs and time elements 
to a process model to clearly show the flow of materials and products, and to depict 
process efficiency. 

W 

Workflow 

This is a generic term for the sequential movement of information or materials from 
one activity in a process or subprocess to another in the same overall process. As 
applied in the CBOK, this is the aggregation of activity within a single Business Unit. 
Activity will be a combination of work from one or more processes. Organization of 
this work will be around efficiency. The activities in the workflow will be shown as a 
flow that describes each activity’s relationship with all the others performed in the 
Business Unit. Modelling will show this work as a flow that describes each activity’s 
relationship with all the others performed in the Business Unit. 

Workflows can be manual, automated, or more likely a combination of both. 
Workflow models often include both the diagram and the specific rules that define 
the flow of information from one activity to the next. When used in conjunction with 
the workflow system or engine, it usually refers to a software-based workflow 
system that will move information from a database to one computer or organization 
after the other. 

WSDL 

The Web Services Description Language (WSDL) is a standard way of defining an 
SOA service interface. 
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Web Services 

Web Services are a set of standards that enable the integration of web-based 
applications. In BPMS, Web Services are used to move data and initiate processing in 
applications that are not part of the BPMS solution operating environment. 

Web Application 

A computer program or set of programs that are called from a web portal and used 
to perform a given business function — such as purchase a product. The term may 
also mean software application that is coded in a browser-supported language (such 
as Java) and reliant on a common web browser to render the application's 
executable over internal networks or over the Internet. These applications can 
either be purpose-built or purchased from a vendor; they usually link to other 
legacy or special-purpose background applications that can access multiple 
databases or perform given functions in the background while the web application 
continues to interact with the application user. 

Web Portal 

A website that provides a single point of access to information over internal 
networks and/or the Internet. Web portals usually provide access to specific 
information and capabilities that a company wants to make available to a broad 
range of people in a consolidated manner. Well-structured web portals allow users 
to personalize their views. In addition to information gathering and sharing, web 
portals can be built to include workflow management, work group collaboration, 
and content management features to help deliver self-service support. 

§ 

Thank you for supporting the Association of Business Process Management 
Professionals ( ABPMP ). Our goal is to constantly improve the discussion the 
authors presented in this book. Please send comments and suggestions to 
ABPMP at http://www.abpmp.org/. 
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BUSINESS PROCESS MANAGEMENT 


Business Process Management (BPM) is a management discipline that 
integrates the strategy and goals of an organization with the expectations and 
needs of customers by focusing on end-to-end processes. BPM comprises 
strategies, goals, culture, organizational structures, roles, policies, 
methodologies and IT tools to analyze, design, implement, control, 
continuously improve end-to-end processes and establish process 
governance. 
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